From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-04.nifty.com (conssluserg-04.nifty.com [210.131.2.83]) by sourceware.org (Postfix) with ESMTPS id AECA63858401 for ; Tue, 31 Aug 2021 08:55:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AECA63858401 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-04.nifty.com with ESMTP id 17V8tL4K017152 for ; Tue, 31 Aug 2021 17:55:21 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 17V8tL4K017152 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630400121; bh=Jl/40/JQC5RV1TRRUHArZaqoudDrSuDJYyQ2IU03fuI=; h=Date:From:To:Subject:In-Reply-To:References:From; b=YY9I3bvC+ChV3uxMoaUmlPopHsqUrRYoDxJRLowclcNZaJEnskbdUXkouAWCipUEX lvmVejjj1N9pSohfiJo2ZHWyjLutWU6xVEH5HAdsvmLDqz6kVeXzKfinsFkEnH0Clr WADIOuK6NY4iInSXYID5kKvgz2mMLZvaonWIn/erX2ZSm2tNr1tkl+uhI+mzEOA4ac ZcPDCc1ygVArGm3d28Ty7uQDib/QsotRs5PBsu/J0sfRUTaLF4Th7DzHpp4bOT3JQ1 ZFor8JRbiLMVWQsglD7U8W3oU2rD7qpA3fZvYmUo80d5U6rgRiTzW5M5ZlZKEfd/yc wgfdk/VGsq7jQ== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 31 Aug 2021 17:55:34 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210831175534.21edae2356d74a0750c686de@nifty.ne.jp> In-Reply-To: References: <20210828184102.f2206a8a9e5fe5cf24bf5e45@nifty.ne.jp> <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp> <20210830091314.f9a2cb71794d0f68cdb5eba7@nifty.ne.jp> <20210830092259.52f7d54fc3fa340738373af4@nifty.ne.jp> <529d7dd7-d876-ca51-cc1f-e414d3c24f71@cornell.edu> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Tue, 31 Aug 2021 08:56:00 -0000 On Mon, 30 Aug 2021 22:14:15 +0200 Corinna Vinschen wrote: > Hi Ken, Hi Takashi, > > On Aug 30 19:00, Corinna Vinschen wrote: > > Ok, let's discuss this. I added more code to my testcase and here's > > what I see. I dropped all data from the output which doesn't change. > > [...] > > - InboundQuota and OutboundQuota are always constant values and > > do not depend on the side the information has been queried on. > > That certainly makes sense. > > > > - WriteQuotaAvailable does not depend on the OutboundQuota, but on > > the InboundQuota, and very likely on the InboundQuota of the read > > side. The OutboundQuota *probably* only makes sense when using > > named pipes with remote clients, which we never do anyway. > > > > The preceeding output shows that ReadDataAvailable on the read side and > > WriteQuotaAvailable on the write side are connected. If we write 20 > > bytes, ReadDataAvailable is incremented by 20 and WriteQuotaAvailable is > > decremented by 20. > > > > 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. > > > > Long story short, I have no idea how to fix that ATM. > > Well, what about keeping a duplicate of the read side handle on the > write side just for calling NtQueryInformationFile? > > Attached is an untested patch, can you have a look if that makes sense? > > Btw., I think I found a bug in the new fhandler_pipe::create. If the > function fails to create the write side fhandler, it deletes the read > side fhandler, but neglects to close the read handle. My patch fixes > that. > > While looking into this I found a problem in fhandler_disk_file in > terms of handle inheritance of the special handle for pread/pwrite. > I already force pushed this onto topic/pipe. I tested your patch attached. Unfortunately, select() does not work as expected for write pipe. Even if the select reports write pipe is available, writing to pipe fails. It seems that your patch fails to detect pipe full. -- Takashi Yano