From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2135.outbound.protection.outlook.com [40.107.101.135]) by sourceware.org (Postfix) with ESMTPS id 2A07B3858408 for ; Sun, 5 Sep 2021 20:27:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2A07B3858408 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cornell.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cornell.edu ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ce7jhcqVlMDAEiZBNuUU4IEEDZxvfcDiev8+wDATfRRszT5lKIY0N2E5fHbQTEX+qHosdz705YA8L1E0h+yR6r7iN278zwLyH5CJmbJ2/8sldCjaz8cr0aHKGu/0vU8Gjx8d1yk4UR6VXsHopu1qXlptHEzqAEUYXAgq011Un4OqY8u3sxaZot8UM3fTx/20o5CbHbSyCzX3NGcRRKRBT7Ra9rgjp4YyrZJ4soq7Erc99OLLuq0iHDYFf56p5K/WmOqDtK+cLX2CMXthzFAHDF0W0CmGnVdMlKhqFucbc0qUIwD9rl7jqjiIaR7yDLxLFryEYDM4x25io1oN+fSFhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZdYXgrSXZ+4Jzf4QrV9Jc/A1Ab9aH3R4f9TEvfJP+V0=; b=bFZKscchJTh0e2Pv0Lo62+KZPnVTDY7dPCFzIUwLnPiHlE5H1vl7XM+DsYilJbEvNzvGEwnj+t2iFRnUXYjG0sdZ4lr4RinoA+gcciHvciMEmU7Bl2jP6aB36Y9g0nPoOuREsc1PV4f1rxbBqtYY3Tvrd8bjZpDRbCwr12nmVCy7Vd4yuFkiPpLdSxNyy5hVNm8b08rDTuCmmVS11xoNnECiAIDtKlmnHAzQVA+Xb+0n/BMDJahV51zGbH2wWkvC4v1rjGmK3nNEoejGbg4BK8J0Gl4efmZsAuK8hfZL3xnRdMa3L4TJ+QqD6F9AqRtjJh4sLG6pV2l3H5pmz8VtVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZdYXgrSXZ+4Jzf4QrV9Jc/A1Ab9aH3R4f9TEvfJP+V0=; b=ekgUDXMR1vJ/ES+gjBwR0RmJWU5H2CCQgKh/syzPRpYeVnAhA2sI/BIzyjDlak4aCI4OZgDU0+Myh8RAXLoQmTQtc5RQ2fRH1UNDWk/Wawqv4nEgara7LTlcpLB+Q924N47zr59wnbADzRnzkvrtVxsWzffuwX9p/TZwIFlVe/s= Authentication-Results: cygwin.com; dkim=none (message not signed) header.d=none;cygwin.com; dmarc=none action=none header.from=cornell.edu; Received: from BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) by BN8PR04MB5954.namprd04.prod.outlook.com (2603:10b6:408:5d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Sun, 5 Sep 2021 20:27:40 +0000 Received: from BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::b510:889b:1fd0:d80e]) by BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::b510:889b:1fd0:d80e%7]) with mapi id 15.20.4478.025; Sun, 5 Sep 2021 20:27:40 +0000 Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? To: cygwin-developers@cygwin.com 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> <20210906050950.56b397be7c5eb3da848691e9@nifty.ne.jp> From: Ken Brown Message-ID: Date: Sun, 5 Sep 2021 16:27:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <20210906050950.56b397be7c5eb3da848691e9@nifty.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH0PR03CA0028.namprd03.prod.outlook.com (2603:10b6:610:b0::33) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) MIME-Version: 1.0 Received: from [192.168.1.211] (74.69.128.111) by CH0PR03CA0028.namprd03.prod.outlook.com (2603:10b6:610:b0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.17 via Frontend Transport; Sun, 5 Sep 2021 20:27:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a083a1ca-0ffe-4cb9-2096-08d970ab9b47 X-MS-TrafficTypeDiagnostic: BN8PR04MB5954: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jcJyztLXMZ3AdC8JX13ESIk9qEQhMnDNCb6bxX01jdNKehP0Xuqgjg7S6gOH6Ov2pOEPehQnTduLjHhEnT3292gN31Xs4SDX6hHbRbb3SP/MGg83CPb9Ty6EPW83H40uMs3ml0xg5raNYyY2iTAmmkOEOtXPcs0BHvst0Q/oWndpBGU3FwjZodLPXaT2LPdx9HcPjZi2w7hKamYStSMI8tgRxN6JNuZ34MvMdmXrfANAiOXLKPFjiVikEzSNpI3a53JhGzJBUH7XG2oYJwr780r3xA6WfH+MYkS18iUZR26xm6hnfZbWXkaKPBto8l3R1UI8N7k1MFv9i5noNVqVrlrSX926Xfr8ct04hOZxcXZrH0wwQSoa8gWA+/vJMnMxga8liZJqGkf462IyhxCTqw7X8gCBpRiTw5tl03JBuN2bAtBjBJjlsqIiBUewpf1vw9IvqdyYrNCEq6gWzDbbwa0Ylnga+U5iikLWGarMWQVAcXuEVdrAIpo5wGrpbmTI0EEP0VXh6bIF1en+HSatP6kcEDnl1tLEYeiG3ada6Gmt+ZfJFbey8twD+xhCAyiUI8HD/+fqbgNyhfHy+8kgGuTYOPxTi/+MMTifPoWVyp256H8Rhya0qYgbNCG8MuP/Kugl0I1ynrE0kYLjh2n5lZrW4cV+rnQB/yI0Ab1RayBBjfs8Hd5lJD5NhFMyo6eaIk96Uqc+w8vjTPNM3jkoVTIP3PHc92GNNB/XjJ6h2aIw1xPZ4Mw3OENjkuUvFrfOQYf//3Z6N+pnf3gkmvTNmKai0SPouM9RCSUu+BbtSNgZNgEdOcjuhWhLZ9ccNACV X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR04MB4388.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(396003)(366004)(136003)(376002)(66946007)(2906002)(66556008)(66476007)(8936002)(86362001)(31696002)(5660300002)(75432002)(38100700002)(478600001)(966005)(6486002)(316002)(16576012)(31686004)(956004)(2616005)(8676002)(83380400001)(53546011)(6916009)(186003)(36756003)(26005)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?oFBP6AhixHrmNQHMbOeEzNa2smuiV8vv64liVAKgYWnRyirTNqEln2IV?= =?Windows-1252?Q?UuYjlbtAWSSTRCCZj4nxNQAa+YyblijaidGNkgEQzg4Skx7/c7B+ZATt?= =?Windows-1252?Q?H6mr6zlmNO4RU8QQDCiNAyw73Q9ylbBw64EndKwu20SHgKpuYY8u6kz+?= =?Windows-1252?Q?UDt2rPZf643/4h07X1ZyQQtkxmtx9hiXvESf+EemXtPVFTvqZU2DZbRT?= =?Windows-1252?Q?50mDc668O0okwjMJdrxBXWXWeyvkSaLFcL0ZL5wNMZn7EPm4yISYv5ES?= =?Windows-1252?Q?hDh1HnpQ17m9JzqwdDaj59+7ypbbd0/IXSaIN2FsHHI098HG1pvd3/GD?= =?Windows-1252?Q?Hf3aW8jebQx9eNHO5NoaTrPaAhpxvHDzUm+jrVSO2XrmsESWcK+2v18B?= =?Windows-1252?Q?1LxuBYBCV2DNzpWSLKZPXomvNqjFb7LSotxZAcifgds98uXSjVQC9Uca?= =?Windows-1252?Q?fpQe7enBDwGXgWPBshrOoJLDDL6BxL8Bitv9pAW39aMjwcZpPPI0ne0z?= =?Windows-1252?Q?NOjaRMPZt1KJWDDIiaBAWszJ3Pp3rl9aVYJZsSE2J7Ixi98JI1YnhhYa?= =?Windows-1252?Q?3NO3XScnWHzUQAnlj9ccRsMLMDLWor17yirG4iWs7jNcAwVX0DXuY9pI?= =?Windows-1252?Q?zSFZGdl2E/EVR2ioY5st7XuNkO59T08s531u8rMPp+VUDl7vRr/iczbu?= =?Windows-1252?Q?oBLMxvsvUMcAdUpHgFt4ZJr7g8QggEqx8Xflqj8CqBBqYKS2nDZlY1cX?= =?Windows-1252?Q?1Gi/0v44Q5MpWZf5OscFhqhAIcpc/SK3I3IcKQz+IjqywDGvTWeF4aHr?= =?Windows-1252?Q?bSbbm741K8j6WftXMDN2p/XZ3WlqzIs5FijDeS75samJr1q12ntE/BMe?= =?Windows-1252?Q?1WkW5mfuXy+qDG0oxgX8jLnsLxTw+r8n8cJSpX5VWumEICHsuoQg7Qy5?= =?Windows-1252?Q?fO0Jv9UOt6g2qHffNa9MpKCAul3pqTso4LbqZQPV0BfESGc9iRmTR3Pi?= =?Windows-1252?Q?ppabphe0RvZLQrQQFVMUk5dk6uvFXO78nMNlTLInW4JJc7dH2dcPHLNA?= =?Windows-1252?Q?kAqGUj4Pz7oM7fDVQenDithjqRtQbBUDG1qlQZRrEZmlvnbmq5XpXLzJ?= =?Windows-1252?Q?bWLpHtvV8R+TJ4D+tlyj6p/Xt7g907JSIeRBHso+iYoGP2q/J+Rv3S3H?= =?Windows-1252?Q?viD+0DLc5B47MU1/FWX8mtCBDgPf7tKdWd+OFA9Ug6X1c2MaM9Jkp2Pp?= =?Windows-1252?Q?zgIkSS+FEl0wtmoXJ3jzfIQIrPTJLq8g3orJa79Fsusvejy7is8SV0Qn?= =?Windows-1252?Q?trnA/6LbQgBr//Ljf49/UpNFo+doFKcJV8LpFufeMLMZS0HtlZcbkmo9?= =?Windows-1252?Q?tRH04dR9rs7V13cEpXLmqtZRt0ciRIc9JyR6Gkczu+Rz31DmMhDc1dvi?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: a083a1ca-0ffe-4cb9-2096-08d970ab9b47 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2021 20:27:39.8752 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jKbS7UbxAMKpYsKX7t0P4WdhbBaLmOfbGkLJgX8eIVOXL7X0E/yOrW2khosdxyyTDsHd3OZJ5ZoZ5PRoD8vyhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5954 X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, 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 20:27:45 -0000 On 9/5/2021 4:09 PM, Takashi Yano wrote: > Hi Ken, > > 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; > > Could you please try attached new patch? LGTM. And it applies cleanly. Maybe I did something wrong when I thought it didn't apply. Thanks. Ken