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 13AE73858401 for ; Sun, 5 Sep 2021 19:42:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13AE73858401 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 185JgRxD016939 for ; Mon, 6 Sep 2021 04:42:27 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com 185JgRxD016939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630870947; bh=Qhf+AwaHhqd8+X6Pkh7ZvC/JN1QExJROU8JIQSMoTPo=; h=Date:From:To:Subject:In-Reply-To:References:From; b=YZxhnVHtUn2/xBqJamMfb1vhXydOPNzrTPRZE6c2sKny+kl+ZQwNPBtEwJCtNqydk /yUe2uKDFoonazeKKp4sF/up3HLNkcEKUxesiVQiREj0DxckySic3nBBd4X8sinPrF jwyaRE3bNVbntbv5df1zasJDz4apjIkp7+SpjLaw3MoeH5UQpgRLjUFjXhTmoMRcd1 9Q1V8YoZYqklfDMiLhXm62OOzj0HRZl6g1vv8HjQt9Ep7nDQrXMRsC1I6nF5Ramy3i FBlu3asWWAuEUsUbG8NdpyLOlxxP+0CQr4IBJOeDffNfJCZTT1n9CO9zj15uhHW814 ji358+hj5BE0Q== X-Nifty-SrcIP: [110.4.221.123] Date: Mon, 6 Sep 2021 04:42:33 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210906044233.43a60635809d801d433fbc65@nifty.ne.jp> In-Reply-To: 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> <20210905225037.c625ee0bcd479181848763f8@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=-12.0 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: Sun, 05 Sep 2021 19:42:53 -0000 On Sun, 5 Sep 2021 14:47:26 -0400 Ken Brown wrote: > Hi Takashi, > > On 9/5/2021 9:50 AM, Takashi Yano wrote: > > 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 > > The patch looks great to me. Two minor nits: > > 1. The patch doesn't apply cleanly. Could you rebase it against the current > HEAD of topic/pipe? > > 2. There's no need for chunk to be less than the number of bytes requested if we > know there's data in the pipe. So maybe something like this (untested) would be > better: > > ULONG chunk; > status = NtQueryInformationFile (get_handle (), &io, > &fpli, sizeof (fpli), > FilePipeLocalInformation); > if (NT_SUCCESS (status)) > { > if (fpli.ReadDataAvailable > 0) > chunk = left; > else if (nbytes != 0) > break; > else > chunk = fpli.InboundQuota / 2; > } > else if (nbytes != 0) > break; > else > chunk = max_atomic_write / 2; > > if (chunk < left) > len1 = chunk; Thanks for the advice. As for 1., is not the current git head 866a62037e235d558584e821a11d60d848e06234? In my environment, patch can apply cleanly by git am. -- Takashi Yano