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 BD05B385700D for ; Mon, 30 Aug 2021 14:12:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD05B385700D 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 (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MZCKd-1mY61M2azh-00V7RM for ; Mon, 30 Aug 2021 16:12:29 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 37352A80DB8; Mon, 30 Aug 2021 16:12:29 +0200 (CEST) Date: Mon, 30 Aug 2021 16:12:29 +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: <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> <26109994-4ac6-3fbc-bcc7-34287ec9090f@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <26109994-4ac6-3fbc-bcc7-34287ec9090f@cornell.edu> X-Provags-ID: V03:K1:22p9BvXpuTpWgn914tDjpURKwLAIKfuVBnuZUUNcGZhaKWGnDSG 2FKVwSdJ/cwW2+ibpb5dUETXytc2Xc5paQEKvRz07IqsdYq5013hRYWN50SHMxr515wfIU3 gjL8zDCa58M6X1g2x4gjZEv98YTLUL2tlfPOAdy3ak1Xi9yiImaJioHKsYuivcxNZjRNsyv 2HNKehFFxx8IeLMiUj35w== X-UI-Out-Filterresults: notjunk:1;V03:K0:FMmQFALdvso=:Z6look6bwMQwcbWpVR7V/q U5QaiORCwyf60k0LcCvdGnXeOnxXiSz2eNaCjlcKozTDZZpEGOvRfSBh0/l+waEfxmc7nlcqj Rmctv1r9X6GmyRJLf7lBDxx17Ih0BbuYYc70myXbnTMUe/QPL2eZgEP3H80wWEgm1pa2Yzomm jgRIoP2st9SDdAMpRvXAFj78gvirESn4a3st7j8oQqJgF46mhaPtQVxaTrfCuE6bjszzD6BG1 W4MGmLvc/9Ir4XwUt14XF8c5W7036a0U+wlr9LIaMTVa+INXZpzaR1Tx/hnM92qpAPsPZ8Zuk en6MYDUV5VJE3IILQ8KPLOmip4GqPte76gFo6WsVMf3NpEmZYQfU86r5r/wga5apzjBTv2OdJ LqITw9+74woC6l9Ind93vBxbZxuilfWHBu2gqn6xg1efwhMvHXS1NuzoLBzLZk+G5RLclVtB+ WZsrFH+P9mGXaAqQfjGNR/22aLzZNHloLi/HMhVvJHGFcsERtadEf+8Nhe6TJI2x0AShBIcd/ meJIQoh9YBlI+0Cy5FCy+Wr9e/w654ddLTVU+nJzPISHWVtnSr1QOb6huZ4athlsyyUtjzrRA BuFemsTZYD2HceOUdwQWNqIGZvW4V1+2m5v4X//KBCHCXvCAE83E2FRkiTEibrwo1C0r3fLru XmdKodTaJYREN4M0LC8VvAaAHOMxSuxeTn8AG71bZNpZRQFdBsceI/JL5f2qezUtiPysWbpes 3tNwRzVFRfOA3Zo6ygTOsYz61wIOuRz+58YmdoFCbbxPO1ojHJTRaguL+8w= X-Spam-Status: No, score=-100.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, 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 14:12:42 -0000 On Aug 30 09:41, Ken Brown wrote: > On 8/30/2021 9:20 AM, Corinna Vinschen wrote: > > On Aug 30 15:00, Corinna Vinschen wrote: > > > On Aug 30 10:27, Corinna Vinschen wrote: > > > > [Moving discussion to cygwin-developers] > > > > > > > > On Aug 29 11:57, Ken Brown via Cygwin wrote: > > > > > 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. > > > > > > On second thought, I'm not so sure how to block on non-blocking pipes > > > on writing. Assuming a write fails because the buffer is full, we > > > don't have a waitable object to wait on. Unless the pipe handle is > > > signalled if writing is allowed, but that would be a first in Windows. > > > So in theory this would still require overlapped IO. Does that still > > > work as desired if the pipe mode is non-blocking? I don't think I ever > > > tried that... > > > > That probably doesn't make sense. If WriteFile returns without writing > > something, what should overlapped io be waiting on? > > The approach I've taken on the topic/pipe branch is to stop using overlapped > I/O and to always keep the blocking mode of the Windows pipe in sync with > the blocking mode of the fhandler. This seems to work pretty well so far, > although problems could certainly show up after further testing. Erm... afaics, fhandler_pipe::raw_read and fhandler_pipe::raw_write are still using overlapped IO on blocking sockets. Otherwise, how'd you handle signals? Just to be clear, Windows pipes can be read/write in three modes: - non-blocking (FILE_PIPE_COMPLETE_OPERATION) - synchronous (FILE_PIPE_QUEUE_OPERATION, non-overlapped) - asynchronous (FILE_PIPE_QUEUE_OPERATION, overlapped) Right now the pipe code uses non-blocking mode for non-blocking sockets and asynchronous mode for blocking sockets. This looks like the most promising approach, afaics. Corinna