From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-03.nifty.com (conssluserg-03.nifty.com [210.131.2.82]) by sourceware.org (Postfix) with ESMTPS id 4CFB3385842E for ; Sun, 5 Sep 2021 13:50:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CFB3385842E 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-03.nifty.com with ESMTP id 185DoXmX019173 for ; Sun, 5 Sep 2021 22:50:34 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com 185DoXmX019173 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630849834; bh=HgVZBo99YZt6jiuEBfqL0HdSYMBM8e7vFTos/sfDpfI=; h=Date:From:To:Subject:In-Reply-To:References:From; b=XkquXwjNaIb8iYS2S73d8mwlroQ5yR9wZR73jw2ElQrTeJqtPDHwTA/LQnkPZL40S qINBYDi/AuAlkPn9fPuchPdPqaiedOf4gjYyLtvXxn80FdhiMnvN4DhJqyHGbWRjAi QMt+a+StXClR02fHGdghI/bxVt3MCzEVVSpGRRGlfHlBIERN3pXAnwL8IyMvYnF4kA A8j0KPv4LQbfQ7e1AQ1kVEkIhFsapkxUeUDiEioD5AMO0L0ALXyUet5rZ5ifdQkBfX 9+mNMbezdkzry8ZV2e9xCstREkpY2GDmfQmHyR+GDXw7cHjy3vHWGsGvMzzhXLhDph w8c7glSrOEqAw== X-Nifty-SrcIP: [110.4.221.123] Date: Sun, 5 Sep 2021 22:50:37 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210905225037.c625ee0bcd479181848763f8@nifty.ne.jp> In-Reply-To: <20210905224059.cfdc8f23d3eeaa1ea16ecf2e@nifty.ne.jp> References: <9ba687eb-f4a0-18f8-b10b-76e7e51e123e@cornell.edu> <152bfc0c-2f72-c684-6fc5-aa7c36c136b8@cornell.edu> <20210903190046.663c60fb11c936e344821383@nifty.ne.jp> <20210903191340.c28ae366e79ca14799bacc1f@nifty.ne.jp> <20210903212205.acc2fc68cc4ffce9c1db3dd9@nifty.ne.jp> <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> 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=-11.9 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, RCVD_IN_MSPIKE_H2, 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: Sun, 05 Sep 2021 13:50:59 -0000 On Sun, 5 Sep 2021 22:40:59 +0900 Takashi Yano wrote: > On Sun, 5 Sep 2021 08:15:23 +0900 > Takashi Yano wrote: > > Hi Ken, > > > > On Sat, 4 Sep 2021 10:04:12 -0400 > > Ken Brown wrote: > > > On 9/4/2021 8:37 AM, Takashi Yano wrote: > > > > On Sat, 4 Sep 2021 21:02:58 +0900 > > > > Takashi Yano wrote: > > > >> Hi Corinna, Ken, > > > >> > > > >> On Fri, 3 Sep 2021 09:27:37 -0400 > > > >> Ken Brown wrote: > > > >>> On 9/3/2021 8:22 AM, Takashi Yano wrote: > > > >>>> POSIX says: > > > >>>> The value returned may be less than nbyte if the number of bytes left > > > >>>> in the file is less than nbyte, if the read() request was interrupted > > > >>>> by a signal, or if the file is a pipe or FIFO or special file and has > > > >>>> ~~~ > > > >>>> fewer than nbyte bytes immediately available for reading. > > > >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >>>> > > > >>>> https://pubs.opengroup.org/onlinepubs/009604599/functions/read.html > > > >>>> > > > >>>> If it is turned over, read() should read all data immediately available, > > > >>>> I think. > > > >>> > > > >>> I understand the reasoning now, but I think your patch isn't quite right. As it > > > >>> stands, if the call to NtQueryInformationFile fails but total_length != 0, > > > >>> you're trying to read again without knowing that there's data in the pipe. > > > >>> > > > >>> Also, I think you need the following: > > > >>> > > > >>> diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc > > > >>> index ef7823ae5..46bb96961 100644 > > > >>> --- a/winsup/cygwin/fhandler_pipe.cc > > > >>> +++ b/winsup/cygwin/fhandler_pipe.cc > > > >>> @@ -348,8 +348,13 @@ fhandler_pipe::raw_read (void *ptr, size_t& len) > > > >>> CloseHandle (evt); > > > >>> if (status == STATUS_THREAD_SIGNALED) > > > >>> { > > > >>> - set_errno (EINTR); > > > >>> - len = (size_t) -1; > > > >>> + if (total_len == 0) > > > >>> + { > > > >>> + set_errno (EINTR); > > > >>> + len = (size_t) -1; > > > >>> + } > > > >>> + else > > > >>> + len = total_len; > > > >>> } > > > >>> else if (status == STATUS_THREAD_CANCELED) > > > >>> pthread::static_cancel_self (); > > > >> > > > >> Thanks for your advice. I fixed the issue and attached new patch. > > > >> > > > >> On Fri, 3 Sep 2021 17:37:13 +0200 > > > >> Corinna Vinschen wrote: > > > >>> Hmm, I see the point, but we might have another problem with that. > > > >>> > > > >>> We can't keep the mutex while waiting on the pending read, and there > > > >>> could be more than one pending read running at the time. if so, > > > >>> chances are extremly high, that the data written to the buffer gets > > > >>> split like this: > > > >>> > > > >>> reader 1 reader 2 > > > >>> > > > >>> calls read(65536) calls read(65536) > > > >>> > > > >>> calls NtReadFile(16384 bytes) > > > >>> calls NtReadFile(16384 bytes) > > > >>> > > > >>> writer writes 65536 bytes > > > >>> > > > >>> wakes up and gets 16384 bytes > > > >>> wakes up and gets 16384 bytes > > > >>> gets the mutex, calls > > > >>> NtReadFile(32768) which > > > >>> returns immediately with > > > >>> 32768 bytes added to the > > > >>> caller's buffer. > > > >>> > > > >>> so the buffer returned to reader 1 is 49152 bytes, with 16384 bytes > > > >>> missing in the middle of it, *without* the reader knowing about that > > > >>> fact. If reader 1 gets the first 16384 bytes, the 16384 bytes have > > > >>> been read in a single call, at least, so the byte order is not > > > >>> unknowingly broken on the application level. > > > >>> > > > >>> Does that make sense? > > > >> > > > >> Why can't we keep the mutex while waiting on the pending read? > > > >> If we can keep the mutex, the issue above mentioned does not > > > >> happen, right? > > > >> > > > >> What about the patch attached? This keeps the mutex while read() > > > >> but I do not see any defects so far. > > > > > > LGTM. > > > > > > If Corinna agrees, I have a couple of suggestions. > > > > > > 1. With this patch, we can no longer have more than one pending ReadFile. So > > > there's no longer a need to count read handles, and the problem with select is > > > completely fixed as long as the number of bytes requested is less than the pipe > > > buffer size. > > > > > > 2. raw_read is now reading in chunks, like raw_write. For readability of the > > > code, I think it would be better to make the two functions as similar as > > > possible. For example, you could replace the do/while loop by a > > > while(total_len > > variables, e.g., nbytes instead of total_len, or vice versa. > > > > Thanks for the suggestion. I have rebuilt the patch. > > Please see the patch attached. > > This patch seems to fail to adopt to current git head of topic/pipe > branch. I rebuilt the patch to fit current top/pipe. > > Please see the patch attached. Small typo. - pipe buffer size. Every pending read lowers WriteQuotaAvailable + pipe buffer size. pending read lowers WriteQuotaAvailable should be: - pipe buffer size. Every pending read lowers WriteQuotaAvailable + pipe buffer size. Pending read lowers WriteQuotaAvailable -- Takashi Yano