From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by sourceware.org (Postfix) with ESMTPS id E3A5E3858D35 for ; Mon, 30 Aug 2021 13:00:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E3A5E3858D35 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 (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mg6Na-1mvO1n2nKI-00hfbP for ; Mon, 30 Aug 2021 15:00:41 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id DE555A80DB8; Mon, 30 Aug 2021 15:00:40 +0200 (CEST) Date: Mon, 30 Aug 2021 15:00:40 +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:BLK2hhPCQw4uZZ+xc38ib1tcux7j1j1o7orcgD8P01qckziW2aI zWTqe49aIdK5QXbPabJpAU/Qi9OlhVzGMosjg5eFqMylHerZQPXbGGNDMQ0vjJMXyKX6q7x Tv+1HeRBKHFEMULqyzQ6cWfu6LMW6jl5/RLykmrOcpCkzv47lLH9haG64oAO8A2Hri/PB2f oRRynkaasF9ultarIghwA== X-UI-Out-Filterresults: notjunk:1;V03:K0:2ltHWKZvy5s=:OskKESdrHdsHt3RAWv7F7j 3wSu/Igd+/S64aUIxsJxcM3sl2yMbwJucwoKqMcXWzW0mEp/YF+yoc/Dx9Q7AOblTxEMTe2Vy nyI6dI5Sg6gO5pK+OZlz+I7eJerXZknYh63XdD9ecWAbO1KdChd6oYqqSeFU7GXnH5LEhAGBY rrEUNFF8aYgpBNQzeengSiXcaC3dD4PZqRGkvQEJgJ7IRogDSA6oFOKIAw6i40ByO50NlHDpL BW+TnAhJyI8i9oGMRCGOhF034UhWRJTosHjkuirDtZE3x+NyPH6rUZP8vCMvQn/5UpWG19jnd QZrY5giZCGfjP2l+J9NHnFymWfrQ7E4yFN+727aAkC3y+wcDrWeh/nG6BZgoy/rR1uPPV8Exv LNQHvlIXOQpfdNumbsFhvE/76bcX9y7lueilWIgyZwdQ1Skm7Q8Cz4vcKjGaYMfGl/ffvIj// KlIF6Rzt4KPk77p9TtYUozLLnVb27HjB0z37wNX1TzOGiwzIGrYsFwyms4DGjpTR9hh6gjFXQ OIym0JLnoCvvgtoOQmpk2D3QUFIYXuPF1DRMiQzwVs3F4pBsxZ/ZCiUCCk9LPWB/r6CzwjCXs NwoRwvHC9kjTn+IefRizXAcxXvJx84rbKPX18UuYI3DA8oDgyT/JyB+RkeFlgkf2RFPJFySOR txLQM4SUmA5ukNuw59ajNfiUcP7GMjst85ZsKEuQteh72NGrhoJLkzG060QSZTEQ15EfBrHqO 2JoA0rUEIjIxbiIjcTjiENhvlaEfh5WGw9d6mrOgZn2zd9FDetBSGSJJ6Fo= 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, 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:00:53 -0000 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... Corinna