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 6B5263858417 for ; Mon, 30 Aug 2021 13:20:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B5263858417 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 1MlO5j-1mhxgK0gjV-00lpY0 for ; Mon, 30 Aug 2021 15:20:25 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 8E092A80D72; Mon, 30 Aug 2021 15:20:24 +0200 (CEST) Date: Mon, 30 Aug 2021 15:20:24 +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: <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: X-Provags-ID: V03:K1:fytaqQa1p/Vv6YYsMT8EOyMORwt0Y9QjV0Gl2t3zNzIHAV7h20E SKNnOmGgq8m4+LQNhUVrrBkhrA3WyWTl1WZ+Ej9e9JEGgrWSO6X7oLK3E7mjSNarWvZCw9u OTCOkbYS2DGHN1j3h8XVBnkVQobHMUjfoyzwle+qAlUi1+uXSdfh+eyHaPpViqRZ/c8mIIm Zg57Lr560hG3N8pbZkvzg== X-UI-Out-Filterresults: notjunk:1;V03:K0:m6iEUZRaa7I=:PJA4APdvm/tdCGlkDxeZEF zonpKGPiL1dibGsworYOFgfBuKdeT13TUmRKyHG4Sanl7RzH5NZsmU95w0bDbzKKGNqAUGaB6 KqVeSjmG1sl4kWIIE8jQndqXVak3SSB3fzBO1ZBOTQlbwTP6J+bsBXWu9bHib90FIDdyb0jY6 VMQKa1/jYLG6D1K+bSv2TeubZ6A5tKxU0tvmoqlTrtsL/xgdIvBktbB1H8ngkf2YBINQ+JWMb D9ml7bEmmgn9atRHrAhlwJV8Dbv96Xkej+5S+Om6o0xeYAc999AILNuXQIWRcPvr/cxmrKOKx Jm3DracR2AWmeHMfJMYooBNmLgia7b6ZL1ZSQGg4Z0YQNu8jQuOfA+7kpZEKvRlUveFwaysFb uBO0xFBvyLNyi/XkNZGt/G5VTFvq0pZfhIt3JFoUv3EODvx26CYoqwyHPvnFyAE1HheqrBVEp TkTVsBANvCRWZ+dlWrUP5F5TWs47zBnWwiK5ivp+ITKLGZxqD6hSJ7fApITNR4OIHyoT82oAx 4qiIGvAgFwKQ1GgdikAjvo7zbZ1Dw/vi2yfu/2TD5VxIIX+jStCXYYVnq/I1wpjrgSezinNd/ Hp2esdiGdNheLbPMQHIO2unvErwLrmJpjVft2iBqfH4/R15frkDkJps+hVy0FJSk5wgshNQqJ j5XtbO9+xZKOcrNjsd2jtfQ3Xzss5UcYVTycbe0sUsVxfiQrS/eX99yeWzcuYGy8AyeseE2i6 l6S/4rmFTl1/ZzQmIyL+SESxc3A+5wrwb+N/EnejbSSe3xmjgqEVXZWnlqo= 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 13:20:37 -0000 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? Corinna