From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-06.nifty.com (conssluserg-06.nifty.com [210.131.2.91]) by sourceware.org (Postfix) with ESMTPS id 4D15A3858414 for ; Mon, 6 Sep 2021 13:17:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4D15A3858414 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-06.nifty.com with ESMTP id 186DGlmN020140 for ; Mon, 6 Sep 2021 22:16:48 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com 186DGlmN020140 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630934208; bh=wdRrUTiz8GIpolD9wo4Pygak877eqG2DNo/ZPpy5Dt8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=j/je/cChcHaJPXlEt+ulB0/IWNoqEuuiKSdOH0HBe6XJWPlsm5nUewE0NN37mlpTN tOkyqlxHH3ovZ6S+NdOygS8zdER4KHuqh02JvkPH3z0GHHSSnBWPisbUXyUa0XHngQ e+dgB3UcmOX/PpJmokORxj610A6VmSyKsjtz0AOLPS2p5on0MEQhZRoQanqrevmjJd DKB99EMMHaU1wQk6g1tQ3MtS/zGRX0PQtkQlVnRFpkh1zUNIBVcdBABHEWt1WxwfmQ evrK0mr/e3eVoSEt2LFE1AdklEJ5+cvouqphtPB4KVVUnrHJiP5jfpW3XLzxGY6RZH iMETmd2u2V6Xg== X-Nifty-SrcIP: [110.4.221.123] Date: Mon, 6 Sep 2021 22:16:49 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210906221649.8001d3cb554011d02309b407@nifty.ne.jp> In-Reply-To: References: <20210904210258.342eb795ac53f1d5352ea512@nifty.ne.jp> <20210904213713.8760e7ba3a4d68fbb78d677e@nifty.ne.jp> <51cb0cef-c3fd-1320-c2dd-a868bf1ffaae@cornell.edu> <20210905081523.0db04d9402abf87635066eb7@nifty.ne.jp> <20210905224059.cfdc8f23d3eeaa1ea16ecf2e@nifty.ne.jp> <20210905225037.c625ee0bcd479181848763f8@nifty.ne.jp> <20210906050950.56b397be7c5eb3da848691e9@nifty.ne.jp> <20210906201643.2e84c0d3a7ac7c8878548408@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=-5.2 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: Mon, 06 Sep 2021 13:17:24 -0000 On Mon, 6 Sep 2021 14:49:55 +0200 Corinna Vinschen wrote: > On Sep 6 20:16, Takashi Yano wrote: > > Hi Corinna, > > > > On Mon, 6 Sep 2021 10:13:10 +0200 > > Corinna Vinschen wrote: > > > If you have multiple readers, all but one of them will hang in this > > > WFSO. They will block here without a chance to kill or Ctrl-C them > > > and thread cancellation won't work. > > > > > > To fix that you have to use cygwait and handle signals and thread > > > cancellation the same way as in the below code following the NtReadFile. > > > > OK. Thanks for the advice. Then what about the patch attached? > > > > > > /* If the pipe is empty, don't request more bytes than half the > > > > - pipe buffer size. Every pending read lowers WriteQuotaAvailable > > > > - on the write side and thus affects select's ability to return > > > > - more or less reliable info whether a write succeeds or not. > > > > - > > > > - Let the size of the request depend on the number of readers > > > > - at the time. */ > > > > + pipe buffer size. Pending read lowers WriteQuotaAvailable on > > > > + the write side and thus affects select's ability to return > > > > + more or less reliable info whether a write succeeds or not. */ > > > > + ULONG chunk = max_atomic_write / 2; > > > > status = NtQueryInformationFile (get_handle (), &io, > > > > &fpli, sizeof (fpli), > > > > FilePipeLocalInformation); > > > > - if (NT_SUCCESS (status) && fpli.ReadDataAvailable == 0) > > > > > > If the readers are serialized anyway, why fetch only half the remaining > > > buffer size? In that case fetching fpli.InboundQuota - 1 is as good > > > as fetching just the half of it, isn't it? > > > > It sounds reasonable. Adopted in the attached patch. > > Patch looks ok. > > I added one more patches: > > - It occured to me that the code is lacking a CancelIo in case cygwait > is waiting for NtReadFile/NtWriteFile. Actually, calling cygwait > without "mask" parameter will result in cygwait performing the thread > cancellation by itself, but cancelling a thread does not cancel the > async IO started by that thread. So I fixed the cygwait calls in > raw_read/raw_write to return to the caller and then call CancelIo > before cancelling the thread. > > I planned to push one more patch: > > - Drop max_atomic_write, it's == DEFAULT_PIPEBUFSIZE anyway > > But then some things were coming to mind, which we still have to discuss. > > - I think setting chunk to DEFAULT_PIPEBUFSIZE - 1 in the read case and > DEFAULT_PIPEBUFSIZE in the write case by default is dangerous. > Assuming the pipe has been created by a non-Cygwin process, the values > may be way too high. > > Suggestion: Actually set max_atomic_write to something useful. > Set max_atomic_write to DEFAULT_PIPEBUFSIZE in fhandler_pipe::create. > In case of stdio handles inherited from non-Cygwin processes, fetch > the pipe buffer size via NtQueryInformationFile in > dtable::init_std_file_from_handle(). Better, in a matching > fhandler_pipe method called from init_std_file_from_handle(). > > - What about calling select for writing on pipes read by non-Cygwin > processes? In that case, we still can't rely on WriteQuotaAvailable, > just as before. > > I have a vague idea that we might want to count readers in that case, > but I have to think about it some more. Current git head seems to have some bug. With and without my patch, sftp get for large file causes error: [yano@Express5800-S70 ~]$ sftp 192.168.0.133 yano@192.168.0.133's password: Connected to 192.168.0.133. sftp> get test.dat Fetching /home/yano/test.dat to test.dat test.dat 13% 66MB 66.4MB/s 00:06 ETAReceived message too long 1728053256 Ensure the remote shell produces no output for non-interactive sessions. [yano@Express5800-S70 ~]$ sftp 192.168.0.133 yano@192.168.0.133's password: Connected to 192.168.0.133. sftp> get test.dat Fetching /home/yano/test.dat to test.dat test.dat 22% 111MB 110.6MB/s 00:03 ETAdo_download: parse: incomplete message [yano@Express5800-S70 ~]$ -- Takashi Yano