From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by sourceware.org (Postfix) with ESMTPS id D7551385841C for ; Mon, 30 Aug 2021 08:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D7551385841C Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M4rHF-1mKLFz1tXr-0023o4 for ; Mon, 30 Aug 2021 10:27:32 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id DD172A80D72; Mon, 30 Aug 2021 10:27:31 +0200 (CEST) Date: Mon, 30 Aug 2021 10:27:31 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20210826062934.54f2f2216021c095bb7ba13b@nifty.ne.jp> <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu> <20210827202440.47706fc2fc07c5e9a1bc0047@nifty.ne.jp> <4f2cb5f3-ce9c-c617-f65f-841a5eca096e@cornell.edu> <20210828022111.91ef5b4ff24f6da9fadb489e@nifty.ne.jp> <20210828184102.f2206a8a9e5fe5cf24bf5e45@nifty.ne.jp> <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp> <789f056a-f164-d71d-1dc9-230f5a41846d@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <789f056a-f164-d71d-1dc9-230f5a41846d@cornell.edu> X-Provags-ID: V03:K1:gFS9EtwwV027n0O2e70ov4Ejc/H71rlAnsvBWeRkmyB900jZi6u 0EK8IPaf4KSNjSeRmL7VuACIXOXgzxVz2dZc9ZNfUAAvnt/h7zXVabYHfVXezYgZI8Mqb7o bAr2l5tmMVxMBLqtsDGbzllRs1VjwATcxOGhk7zPGDvKuyEUDQ5B2M3++H546MtIxmKhgGF qfJhOs0UrSj8AV/2rwoTQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:QGqUMpTILII=:0mDQtbAIGFS0IUYzs0BB+k rHQ1UaE87R9NTzn96/l8Eu5ED3xQRAjM5ElQr1W4WulBPIPY6g9DF9LvTpx63vDXrZKe/9bjV kJYRLw7dzVF3xADckf9a9/WhoLXcrhgt66pvqZF3fT1h6dbWenGPbtUMtnWCe7+JAhE8XXAme 43Wn8MisGJjFm/HV76dI8hJM2dDk09Rc2fCyPGF7UTCHnyhtH7oh/R6ekMz6dn697ZcbJpHN1 PApvWgh3RamjuUuosus1d/oGCW/TiqIeyjWBcXuC9XmNSADnk59+FbEA37K9e/w0CZar4Qk06 rxrpiF8Vldr9bykb+hu3rZro8K+EHK7Z+IkG5012e5XTF1GFLC67mJh01/CNdT10kjaCg8bkc LgT1SAXh6YvJFqnGvWy/S16qv1TwEe/Gu8tJhzYig+oXt8FgpkDw4xaDJmpVh48v0kMq0fMQW 1pdw7DLyaBJjBFxj5b1kNWtu4gFE4/K2V8EEcRUDbRyEc/kToCWNLZM6RlzwR5rw95KZ/2hny D4I2OyZbB11fgsGZv+qZC3r7JogL4AErdbn7OTEVsIu9UMRbm/3VPdw1W4w2BY6/6DunTyCDQ C63MzEq9nKUumljOPtB3fjifvIBkXaacznqGlkd55vrbEroNW+4ZKYSqfbdWM3FZ4Cph51jMd b1jDwecIPCRr7pOjuUD9Y6W5D2hnXnVNU1Nr3qpRx5i0kOqf5weo4tDlAhCKXHgzGsZjPSoWV bRGUrBBMMlEDfw1E86zZH1D8bOIyGVdLUJx+suvKoNwd2X+NKy18vfiLJWA= X-Spam-Status: No, score=-99.8 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 08:27:44 -0000 [Moving discussion to cygwin-developers] On Aug 29 11:57, Ken Brown via Cygwin wrote: > On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote: > > On Sat, 28 Aug 2021 18:41:02 +0900 > > Takashi Yano wrote: > > > On Sat, 28 Aug 2021 10:43:27 +0200 > > > Corinna Vinschen wrote: > > > > On Aug 28 02:21, Takashi Yano via Cygwin wrote: > > > > > On Fri, 27 Aug 2021 12:00:50 -0400 > > > > > Ken Brown wrote: > > > > > > Two years ago I thought I needed nt_create to avoid problems when calling > > > > > > set_pipe_non_blocking. Are you saying that's not an issue? Is > > > > > > set_pipe_non_blocking unnecessary? Is that the point of your modification to > > > > > > raw_read? > > > > > > > > > > Yes. Instead of making windows read function itself non-blocking, > > > > > it is possible to check if the pipe can be read before read using > > > > > PeekNamedPipe(). If the pipe cannot be read right now, EAGAIN is > > > > > returned. > > > > > > > > The problem is this: > > > > > > > > if (PeekNamedPipe()) > > > > ReadFile(blocking); > > > > > > > > is not atomic. I. e., if PeekNamedPipe succeeds, nothing keeps another > > > > thread from draining the pipe between the PeekNamedPipe and the ReadFile > > > > call. And as soon as ReadFile runs, it hangs indefinitely and we can't > > > > stop it via a signal. > > > > > > Hmm, you are right. Mutex guard seems to be necessary like pty code > > > if we go this way. > > > > I have found that set_pipe_non_blocking() succeeds for both read and > > write pipes if the write pipe is created by CreateNamedPipe() and the > > read pipe is created by CreateFile() contrary to the current create() > > code. Therefore, not only nt_create() but also PeekNamedPipe() become > > unnecessary. > > > > Please see the revised patch attached. > > That's a great idea. > > I've applied your two patches to the topic/pipe branch. I also rebased it > and did a forced push in order to bring in Corinna's loader script fix. So > you'll have to do 'git fetch' and 'git rebase --hard origin/topic/pipe'. > > Does this now fix all known problems with pipes? > > Corinna, do you still see any benefit to switching to PIPE_NOWAIT? AFAICT, > it wouldn't decrease the code size at this point, so the only question is > whether it might improve performance. Pipes are already using PIPE_NOWAIT aka FILE_PIPE_COMPLETE_OPERATION mode, see set_pipe_non_blocking. The problem is that it's not used for blocking pipes. Rather, blocking pipes use overlapped IO. Overlapped IO is conceptually upside-down from the POSIX concept of non-blocking. Also, the information returned in FilePipeLocalInformation is historically borderline. For kicks, see https://cygwin.com/pipermail/cygwin-patches/2004q4/005002.html So my suggestion is to try switching to non-blocking Windows pipes entirely, even for blocking pipes on the user level. It works nicely for sockets. > If you think it's worth trying, I'd be glad to code it up on a new branch, > and we could compare the two. We can do this in two version steps. There's no pressure. > Aside from that, I'm wondering how and when to merge the new pipe > implementation to master. It obviously needs much more widespread testing > than it's gotten so far. I'm a little nervous about it because I haven't > thought about the details for two years, and no one other than me has tested > it until a few days ago. I could push out version 3.3.0, and afterwards you can just merge into master. Corinna