From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id 006C53858C27 for ; Tue, 31 Aug 2021 12:31:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 006C53858C27 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-02.nifty.com with ESMTP id 17VCUtBP001861 for ; Tue, 31 Aug 2021 21:30:55 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 17VCUtBP001861 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630413055; bh=ZPROQw/wIkgJbro0N4poXJY9QNr7G5jkRBlOhyEPauM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=PbS09V1L3+Oh70ty5kjcza/CnsfHwsYum7gcVWkROio695IWOm89Xcdu59WTme+n9 /KaUry9i7Z+iHbbBT3hoCBCyhAazL/y2kVEises5yOXikS9KnpUbVqaNMNmUA0P6J4 tlREoDHJrx2m3/NiIy2aH/XHCjXIW9HZkSH4bcdviivnf3wimgYz77gIjrQO5kuedV E/v4o41G7cCuvDF7XAxxlSy7goMIXlqb8N8AqGlempYLHqDsKgzXHnYUYBHm2TxTHg aRBI8617IgztwC6/ofdO3nYpkDs97F9HSQKE1LYZ8uiXTPCXFNOmxKntUG6p4MU8Uv YVgv1fWdIiDBA== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 31 Aug 2021 21:31:10 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210831213110.6c74574c7c43ff85c19cc175@nifty.ne.jp> In-Reply-To: <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> References: <529d7dd7-d876-ca51-cc1f-e414d3c24f71@cornell.edu> <20210831175534.21edae2356d74a0750c686de@nifty.ne.jp> <20210831182500.4c1c67dae13f51ca68964f63@nifty.ne.jp> <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> 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=-10.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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 12:31:25 -0000 On Tue, 31 Aug 2021 20:45:41 +0900 Takashi Yano wrote: > On Tue, 31 Aug 2021 12:18:57 +0200 > Corinna Vinschen wrote: > > On Aug 31 12:05, Corinna Vinschen wrote: > > > On Aug 31 18:25, Takashi Yano wrote: > > > > On Tue, 31 Aug 2021 11:08:42 +0200 > > > > Corinna Vinschenwrote: > > > > > On Aug 31 17:55, Takashi Yano wrote: > > > > > > On Mon, 30 Aug 2021 22:14:15 +0200 > > > > > > Corinna Vinschen wrote: > > > > > > > Hi Ken, Hi Takashi, > > > > > > > > > > > > > > On Aug 30 19:00, Corinna Vinschen wrote: > > > > > > > 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. > > > > > > > > > > Bummer. Is that with byte mode pipes or with message mode pipes? If > > > > > the latter, if you try to write more data than available in the buffer, > > > > > it's bound to fail. > > > > > > > > Both message pipe and byte pipe. > > > > > > > > > Did you add debug output to pipe_data_available to see how the > > > > > information looks like? Or do you have a simple, self-contained > > > > > testcase in plain C? > > > > > > > > The test case is attached. If select() works as expected, the program > > > > does not show "r" or "w". However, with your patch, the program prints > > > > many "w" (means write() fails with EAGAIN). > > > > > > Thanks! I found th culprit, but we have another problem. Even if > > > select returns correct info, A write, trying to write more bytes > > > than are available in the buffer, hangs. This shouldn't happen. > > > Still digging... > > > > That's, of course, correct behaviour for pipes in blocking mode. D'oh! > > > > Please try the attached patch on top of topic/pipe. > > Thanks for the new patch. I have confirmed that above issue > is fixed and select() for write pipe seems to work as expected. > > > BTW, I found one minor difference between Linux and this pipe > implementation. > > The test case is attached. The test case uses non-bloking I/O. > If this STC runs on Linux, the result is: > > 1024/1024 > 1740/1740 > 2958/2958 > 5028/5028 > 8547/8547 > 14529/14529 > 24699/24699 > 41988/41988 > 22227/71379 > 65536/121344 > 65536/206284 > Total: 247KB in 0.000612 second, 403517.628166KB/s > > On cygwin 3.2.0, the result is similar to Linux. > > 1024/1024 > 1740/1740 > 2957/2957 > 5026/5026 > 8544/8544 > 14524/14524 > 24690/24690 > 41972/41972 > 65536/71352 > 65536/121298 > 65536/206206 > Total: 290KB in 0.062653 second, 4628.669018KB/s > > > However, on topic/pipe implementation, the result is > > 1024/1024 > 1740/1740 > 2957/2957 > 5026/5026 > 8544/8544 > 14524/14524 > 24690/24690 > -1/41972 > w-1/71352 > w-1/121298 > w-1/206206 > wTotal: 57KB in 0.000330 second, 172989.377845KB/s > > In non-blocking mode, writing more than pipe space will fail with > EAGAIN in this implementation. > > In Linux and cygwin 3.2.0, it seems to write as much as writable. > > Is this difficult to be fixed? The following patch almost fixes the issue, but atomicity is the problem. diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc index 2dec0a848..0a74a654d 100644 --- a/winsup/cygwin/fhandler_pipe.cc +++ b/winsup/cygwin/fhandler_pipe.cc @@ -323,10 +323,15 @@ fhandler_pipe::raw_write (const void *ptr, size_t len) if (!len) return 0; - if (len <= max_atomic_write) + FILE_PIPE_LOCAL_INFORMATION fpli; + NtQueryInformationFile (query_hdl, &io, &fpli, sizeof (fpli), + FilePipeLocalInformation); + ULONG room = fpli.InboundQuota - fpli.ReadDataAvailable; + + if (len <= room) chunk = len; else if (is_nonblocking ()) - chunk = len = max_atomic_write; + chunk = len = room; else chunk = max_atomic_write; -- Takashi Yano