From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by sourceware.org (Postfix) with ESMTPS id A859A3858417 for ; Mon, 30 Aug 2021 15:16:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A859A3858417 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 (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MEmAX-1mEuFP0C8R-00GJqb for ; Mon, 30 Aug 2021 17:16:00 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5BAC9A80DBC; Mon, 30 Aug 2021 17:15:59 +0200 (CEST) Date: Mon, 30 Aug 2021 17:15:59 +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: <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: X-Provags-ID: V03:K1:e8WQDndt+xSC+aq6ksw9On58HmEKOvJdvnoJG1t8glF5gxpWt/R nPVG7uz7MgxpHMKEy44yZIVxEd7rD+L8RHkw4lEY7ydezooGAj6FA5uPF7WQxl7Jkd2ny1N 44NYTRdLfYSzmnlw4p5bi/KzLOlrAdkrRdoFYrJGt19FaTBFk2CqLx1hYOjtifVmsEBcVwp ZwiWyPk5zKNlNKljqkEGQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:0YQgQKvziNA=:nq7Z20Hp12sosLapTJqX2/ nb4/6wD+5BSPzdixvKZkGlqaybJ8c0iFoYFCR4COAvTNaNIHsi1o/xdKVlK4LjfHQ+r+ycbOV 5qf24vSfJyXxvXl1E+6/BDYM8X8xbwiOyP1rX5Ej7Vi7BQhoNdCQtD1PFbjh1FONEnhzxrs+c Ya0nzPMO9l3RaczD4PUXAkE6TAH75MpBwN5jjFlk9EZ78cuZVb4qzrV8Vu6l9Wo9aXXGqtsDN xQkx4jQcvkGq6AY2NdOwVSrdMq82cuXK1Zi3MQEXYjSs3rUcGI77v+4244BKal5AGe5fPDYkj 2vvATYUDs5Jk/7i884HeR0MtFN2M1DnCO8X1vRfbL6rnZQW3TUeJmq5Mx6oFHLiT9CwZtDR/P /yQYQGLTPOlcI6cNJF4caO/8bWNXNo3q8/KWTyYVo3w/idzLhB/K32cDLyG7GhURDJ20got/a DbsXuCaisNcJZnanVi65Cx8ERzVGIzjZxxJ2tzjVp75yZLqK1iejnqWerPlJPnjpfZu1DoOfP /SYhLIZRJtcqDOiYD76LarbGEvGc7zvcZASN8MQZbvvPpuCepe/EB/CiLUpOLkZjf3+CzLh/4 OFtlynM+0CHS7MFoZ+EEt1vNlqaLQ7PaUaA6yWCAJGJB0OykURGTsusbbXCuI05QerTONyU8s l3BL1sj9XXYhFl4wStFV7tCWrUeWLCcnQNRDSmxbs63Sb1MYl95DAPBeUsfDjTAXgyS6SZVyv nwwfnYoJQbG4C4XOhGxbs0WVij6DKdFWYQ1QYUYGJwHrCdDvzD9iPnhY+CY= 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_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 15:16:03 -0000 On Aug 30 10:52, Ken Brown wrote: > On 8/30/2021 10:12 AM, Corinna Vinschen wrote: > > On Aug 30 09:41, Ken Brown wrote: > > > 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) > > OK, I've been thoroughly confused about what "overlapped" means. I thought > it meant specifying FILE_FLAG_OVERLAPPED and a pointer to an OVERLAPPED > structure, both of which (I thought) only made sense when using the Win32 > API rather than the NT API. > > I *think* I understand what you mean now. By using an event in the calls to > NtReadFile and NtWriteFile in the blocking case, I'm selecting asynchronous > mode, right? Sorry, yes, OVERLAPPED is a Win32 expression only. The NT calls only differ between synchronous and asynchronous calls. For asynchronous calls you can either call a wait function on the file handle or you can add an event object or a completion routine. But that makes me wonder... Looks like my idea to add the FILE_SYNCHRONOUS_IO_NONALERT flag was a red herring. This enforces synchronous operation, which is not what we want. Bummer. However, if C# can't work with asynchronous handles, I wonder how to fix this issue at all. Corinna