From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2103.outbound.protection.outlook.com [40.107.244.103]) by sourceware.org (Postfix) with ESMTPS id 03BC03858401 for ; Sun, 5 Sep 2021 18:47:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03BC03858401 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=Yr8XPFKn83gucFGzOuZkFW0t4TRaQ157sZ9EB8dqPz9eg83EF+rGc7VOEBL8o0OxoF9tF3oL1Hr6x1Y/gN4LRufXz8okJQ6X0lMoApdPBxLWY5yNZD+N/J6D+N+XWG5Rm+4x9euiiYdl1de3AGvNHoZXqhY2gZSbLggSEDIyfQEzDH7p/QHg63moKeaKQ8O0USHfkB5PXgR/+w6VAhWwDF/4nhQDM7XAp+gHMLOIq8og0VyFqiA7sIvrLQnXL8sE3hoZaInYg2jEyLMQlfFDUY/rumfqMLJ15uCXWhAS0OPs/zIgf+g8nfwgODyfZPn9FgKsxK9zcJN1VCcxRcT58Q== 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=zVQaC1dkjuLpJJzDxiceckQ9wSS3Z5lcxtc6BK5R6k8=; b=CMoLOIK8O7kOgrXmPwFoMPlM3frBcVDu3x3fBL7Y1EjTUvfW4n8z/4rq1q8phFizgLlbo0/OP2fYyn1bgHsVFfPEHrmqYK+OlnAaOPFkm48dT28g4NwuKJbz64KlKv3E4PLjjlc1rGdigqZJtC9/vtYrzcy6psugHz8GMdeLlcyn133z+P7XcsfZNUOEtSUMIMAu0s4fKpmBt2p7GpW9VmiGl4hS32kQ8muIF/OKB/gSIWxIX3OfaQrccdVWBICQjO434wYpbpObCPQV0Ch3UJMXGn5r9pElTQOakm6AUVnOwPehPFatBYvj7QKsLVP9mKTJjhdbbW5Zutq3Zvkw7Q== 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=zVQaC1dkjuLpJJzDxiceckQ9wSS3Z5lcxtc6BK5R6k8=; b=IaL8+hPUwCngoqsRxVvqAoqRwWEv/MlcVNAyzwXua8Iu/YeZM7Q6cjsfPQ9bz+zJ7bnLMwtBsvns2OqtzV5UcEusbPw0opU/iNaAzh3ntu9L2fP6V6RS47hKH9T5spJ3QfsEItMg5R6thrpbAFra5R4GQ8LhfFkt8z+0wQF9qsc= 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 BN8PR04MB5619.namprd04.prod.outlook.com (2603:10b6:408:a2::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.25; Sun, 5 Sep 2021 18:47:27 +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 18:47:27 +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> From: Ken Brown Message-ID: Date: Sun, 5 Sep 2021 14:47:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <20210905225037.c625ee0bcd479181848763f8@nifty.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH2PR11CA0024.namprd11.prod.outlook.com (2603:10b6:610:54::34) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) MIME-Version: 1.0 Received: from [IPv6:2603:7081:7e3f:3419:4172:b7ad:cdf5:53cb] (2603:7081:7e3f:3419:4172:b7ad:cdf5:53cb) by CH2PR11CA0024.namprd11.prod.outlook.com (2603:10b6:610:54::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Sun, 5 Sep 2021 18:47:26 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 00d3a97e-8031-40ec-8931-08d9709d9b59 X-MS-TrafficTypeDiagnostic: BN8PR04MB5619: 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: ABbCgk/yqicSwCWKxYSh+fGVOxUBG8Uvy9ZFDyIapR0uloVCxRJ8reQYGUyfTF+FT1T8UsHeuTwepdNwqru4e+q9TE+MDfkfuqFnRoVYojYI3Xb6W4d2qCbDd+AXjdAyaWCNlMEjfTIBV4qs8acqsVVxqttDpZlgRuszvBGF7Acir6c2oMymFJbKGzLiqPkhRD1kO3ZmBqQCHiondL8tyfAwdMfNtIbvvnlYHRNeXQlrgqEaoQTehh2Abw4aUq+yBtIjEZA8wMYYt9/lh9zR3xT3eP5YXAh96+SS/zC2iGK6J7x3+ITjyhuTTsRZth5FDuln3M+qxTvG3Hjb1UYCtVhyHnCwYTnkH8XB68CCBV9CrXI5S6igPvQZ6PE+Ht+Y3eljuLRDlDSn3cPXToTMoEG1/btlppbirtbMRFCRjnsgcm1s2nk63l4M5nqd0f/J4StNAE6h0SIFsQVUKrn8Yk6YvPJZ4yoeWOUsNom41DiFLUqa+/3AvIJSJnancdjeawRjJCDiWsyBBmpdH8FdIjWDl6BV2bbH7NTGgWM+yNP19d8RrWxwwL1Fa1rL6TE4qH1Z2ppoI3tguxl9QUVipZjB1WSkpFhskUe8TR7KvqZ4Nr7fs8HQ6nAauvwswRJmSKR/7bEb6w33OHO0G9Zi6xc90ZVR0Cbxi75alHWANczGpTRCSD7wK6a+FkwmlX6ZwIlefrKz/EtiOXssd8nh6tGr6gwGzl+W8+MqRlsn6UzYfTunUDx9ksd0xvtKnWqKgLQZwwYe/aH06I15Z9XYkmh7GqO5AhQ+T4jxGW/0b6xnYAy+hwKhpiJG04ZCJz3H 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)(376002)(39860400002)(396003)(366004)(136003)(186003)(2906002)(66946007)(966005)(86362001)(53546011)(478600001)(75432002)(8936002)(5660300002)(36756003)(8676002)(316002)(6916009)(31696002)(2616005)(6486002)(83380400001)(31686004)(66476007)(38100700002)(66556008)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?5is3/QQ7tpNPAE2qvCre7EpUGAUWVTVkbM9SuAKuHumhbHQplbxZJXUN?= =?Windows-1252?Q?bSCFpe21pafRxXHK1E/pb1LVGZkVP4S1K+4TDDQ8qtpuj3oTk/8ISjf6?= =?Windows-1252?Q?V3Bog+fYVru5xmkMkk8kMgNaHl7jM31oqwfiERD9sBxGBFJlMWI1i55a?= =?Windows-1252?Q?txa60PnAJ34/Yx2f7u1LF+y5VmfBGJxzoVPs/QN7pDkwo15BM2JTby1n?= =?Windows-1252?Q?bvT1bpaHaVEBaQh3ixl5kYhPfoL3ajng0HeT4C1fc3uwEqnCXtZmIAqd?= =?Windows-1252?Q?AGtfI8AqBKnotOIOSyIvg0A4Li3EnbPt6F54gi95auL2hLd6VxUQAcag?= =?Windows-1252?Q?S04LBccQHkibAUCuAqOdkpcrfcO3hW1f3Qw2Kr+Yoo4pow4MHlYxb7ZZ?= =?Windows-1252?Q?2SmEhALOP4VoxMl48yRu+apIDy9nPwKBSLC/EcYMWw3ckr3KqL0A21Xy?= =?Windows-1252?Q?dx5a+92JrJcd+ryBvdAloQMT38FmRW1dGNYvrEx+J/GnOoeorIUeaePw?= =?Windows-1252?Q?9OFQG/9RdhLWnFTyVf+KWV9SdvmDMQ0tO7FmwzvpPcJpRwQvG96qMnYR?= =?Windows-1252?Q?i7HH8tCsO0S7R+Y2puA0ts4FwEsPclFrdOF2bEsVf4bbBAtBIkTptBJR?= =?Windows-1252?Q?ILAIBNW9DbZKUfwL3hT7JNAbb3M4LSzDuOVVpWMfKosOoq3h+YJrSxNn?= =?Windows-1252?Q?q7UPaXOJE7DTNl3XNRjR+CH0hmuMufiNQSPEggSPGk1E2QfxUfusv+pe?= =?Windows-1252?Q?UHsWAiVhiOptjCuQrQzwjEF+5WiSH+J3LOeRhMZ08YYT/G/zoe7GIEQp?= =?Windows-1252?Q?1doFoAzTz6S6nJvJJNN/QRMvP1Sy/6F635jSygQ9gMiIG+UbiLnCUsiy?= =?Windows-1252?Q?4/FhlkLeUMp3r0iJKf8TK4QaBlvzPrK3h073CH/rwFLCG95yF4kvlDJW?= =?Windows-1252?Q?BlYLW49Pnc6Cac8/h7NiCravJGRxj9oO7ahuHdbo//1A66e4LbBXWAsV?= =?Windows-1252?Q?UQTmpIQdSAYJX6Bb4XFFQHE0Wyqaryzg3DSkvQIWlb6QWr7L9o2tdTj6?= =?Windows-1252?Q?IFeokAyTkaq9R8rf2vuiJIv8F4jpUYdr3BxB6nLExZDLcaLpDA3oNDQ2?= =?Windows-1252?Q?EYe1jTXXDx3PalRBryfXoPmmwkYJ3JgEGRNcuwRLIw/1/huJhdKITGP0?= =?Windows-1252?Q?wlnU4/kZflVVVr0+9yJZeCnxn/pUXYh5qOYzJAxPVFd18CJlRhbxaH5K?= =?Windows-1252?Q?6VexWZxozoaGSJLZgtpFOktFTmp2v8CFY+nNlVBGjNbQ1kQBzhPfuIJh?= =?Windows-1252?Q?IQ9wykzQOF6Xitgpci/rAb67rQXcr4eYDVBbFvLq8jPYcMC+hXViJVid?= =?Windows-1252?Q?k7lzfrueKa71aoPfuRKSOoLQR83/Vzfynh0Y11WPGTu4D4gP1lCCR2Kj?= =?Windows-1252?Q?aIZtQcQac1WpUdqmWRc2hEIe+2FJbC18cEdsgkP+uR20mjfID5kMa36c?= =?Windows-1252?Q?xO2f/MQs?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 00d3a97e-8031-40ec-8931-08d9709d9b59 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2021 18:47:26.9947 (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: yuLeg+VbFalxNqoBiiqlO2mAv+3HfcjlbyYgmutMPEY34BoXfcKfjEzk2Guk7KFPhtpO/t4/9YQ7+UD5Baks/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5619 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, JMQ_SPF_NEUTRAL, 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 18:47:30 -0000 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; Ken