From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id 84AE73858D34 for ; Mon, 30 Aug 2021 20:21:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 84AE73858D34 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 (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MEFnR-1mAaUm3xQ5-00AIZ7 for ; Mon, 30 Aug 2021 22:21:06 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 83437A80D72; Mon, 30 Aug 2021 22:21:05 +0200 (CEST) Date: Mon, 30 Aug 2021 22:21:05 +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: <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp> <20210830091314.f9a2cb71794d0f68cdb5eba7@nifty.ne.jp> <20210830092259.52f7d54fc3fa340738373af4@nifty.ne.jp> <529d7dd7-d876-ca51-cc1f-e414d3c24f71@cornell.edu> <6f4d6673-0128-cc62-3a5a-5b0897fbbf3f@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6f4d6673-0128-cc62-3a5a-5b0897fbbf3f@cornell.edu> X-Provags-ID: V03:K1:5xQUMpO1xykVQzMLrvE3OFI67eYcidh71RJs2mxeFOiimbPqqSv sp5R8rfziAjRZP/WEqohLkH8hBe2NZQtle+5ENvREnH5GuecX59gctWnt1Pv9YgZsVoa0Y2 lMmXQoDGBfA78PIYbsy4IrmIYFG3RW+yb6CMZCcofC687XaC/imuDNf0E4oKI0R0/h7rFNl bSsIVWQhYdeafI0l+lpmQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:5JJqYZE7qwc=:Zh5Sqs+LYu3PNhlQIs7vr/ 5uRGmuOHOaFw7f5V8obiRwoz1IG6tHRVSlpiMXFPxZTMck4Vk5gmPvFrR11XiX+2sKSJxLjr8 rovv8j3oBmAdtQj01paxmxtwstnBkdFPZa4tJnnZZ0RZU9S6M8czh2lBNHZn/l/QeslgVLAEo xl8vfIObg9+fMgvfd3eekEJHZeDuoyKtj0q2mp7Nm5JDSL/YIOQUSqsYfJ3r9i6e24Z4g8/6c NK/iQ1bjbKzNtCsnEhJ8MtaowiUGH2TwnBxR8dtisxDanXeE3uLJCumYygXdshdzYObJmStsM LcFGW88zQDTbRlR3BuxDrkjjhUEPF0jFBtvf6rbqU3rydLfjH9fzyQVyj/geeyPPrQ1p7zAJr 9iGzBuec25BgQOXHxs7a0DcYb6VGlMRTKXvzWMo2M5SCdjpoLdwVw0HovJatfOWQWra8jkK0J kJmseQoMuo69FGgHBs6bHuTnfYbZnTMDRcIiP2AbzfRPCipkkjq1i0e/yEhwjZk2+GUxsGIwl L4d3beQMZBf6OZc9J9kJyBr1KLi28bYD74xVNsYw4dl2IhIkjCRWZHagyWtooBAP9e/wwDZ6N sIFHuCkrEislE/y1dJHXP/mUCKjEXP4TK27v3shvIxiP14VS2v0/OPrb2C/AXQcWimRl6d3R2 QG3f4D7MU804CBesVbYA0o6i8rULZuTedROFgPw+UheyiMIPUjVurs6q6Hml4q6Qxs5D+/tXt N5ZWuWLPW1Rln8+Q+FCPaa80xDTLUD6pl7EeiZLT/7191GrO8/X5l4NxbqI= 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 20:21:09 -0000 On Aug 30 14:59, Ken Brown wrote: > On 8/30/2021 1:00 PM, Corinna Vinschen wrote: > > [...] > > So: write.WriteQuotaAvailable == InboundQuota - read.ReadDataAvailable. > > > > Except when a ReadFile is pending on the read side. It's as if the > > running ReadFile already reserved write quota. So the write side > > WriteQuotaAvailable is the number of bytes we can write without blocking, > > after all pending ReadFiles have been satisfied. > > > > Unfortunately that doesn't really make sense when looked at it from the > > user space. > > > > What that means in the first place is that WriteQuotaAvailable on the > > write side is unreliable. What we really need is InboundQuota - > > read.ReadDataAvailable. The problem with that is that the write side > > usually has no access to the read side of the pipe. > > For the purposes of select.cc:pipe_data_available, we only need to know > whether InboundQuota - read.ReadDataAvailable is positive. If > WriteQuotaAvailable is positive, then we're OK, even though its precise > value might be too small. But if WriteQuotaAvailable == 0, we don't know > whether the buffer is actually full or there's a pending ReadFile. It's > only in this case that we need access to the read side. Any ReadFile with buffer size >= pipe buffer size will trigger that immediately. > What if we reverse the roles of the read and write sides of the pipe, so > that the write side is the server and the read side is the client. We can > then try to use ImpersonateNamedPipeClient to get information about the read > side when WriteQuotaAvailable == 0. It's not a problem of impersonation, it's the problem of not having access to the read side, because the write side just doesn't know what handle in which process constitutes the read side of the pipe. For all the write side knows, it could be some other fhandler in the same process, or some far away HANDLE in some far away process in the same session, sometimes not even a Cygwin process. Corinna