From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2097.outbound.protection.outlook.com [40.107.92.97]) by sourceware.org (Postfix) with ESMTPS id 889293858436 for ; Thu, 2 Sep 2021 13:01:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 889293858436 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=UCYzSCAjOWny2m3AhvXXJVcL7HMdlhE/J2lH5xSMSpOOXrmdb3OGM8khcbb6j0TTiSfr1ABoPP89MPhhIoqtc95p0SQ1bFQXrGWcYfTEfG835C4uVlYN+lKBWF5UpPqyCbmgowPnOPV8vSl3CG65JlRnjfe8pi8Lo2UutNNkeNZQHM+jhHNd/WPe/FfyGFSKrIpDGm4CMq7A+FfHRxL2/hlF/I8yitrjsVp6uSxKzAokY9F89QcQFF6G/KCCHjCO72YI+K4jAIKTc8ulJNoQUJBHeeyPeVMRnOO/eIdiEKIEscgOL+0wDYWXU7zF6RB5l1bwB7eskGCV580HamufBA== 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:X-MS-Exchange-SenderADCheck; bh=+udT5+azYBoNqOS0KvpjxpX8WX9fMw87B1dSC8HHpxs=; b=cidyA+n7ghW+fQOg/ut16rQ4UIyWGpFv1CNo4pA2/eKrL4n2AzxmbfYfnuql5VEJ7nmPhrd9Yn/TkYglKjDc2qa/PLC1sx3La/WoC0kaPTwzdRN8y1y4DV2N5XKV6kM+VHwWuTGGUJ+GXI4hhqfIL7ZWNGDVmuqPljAtWDceotcv2Tjf7BjSO23r1I5BEP65WLu4msXjB7+jS7hhmxrKNutAp48uKDaUBJGP8+mjF78bqPz+hGoZNrZPkR44wOqJOpbfKpqtJ0v05xkm/02ErTSqP3bQ2Ik9kujNwbvlQgFRLRPId/cqGRU9vfHYgR5M9+6jpM9kNEG5ft7j14RvCg== 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=+udT5+azYBoNqOS0KvpjxpX8WX9fMw87B1dSC8HHpxs=; b=d5x8hrSx+2XvrqF8svdSLaVvJMYGSK7/kzit+sBlxBew0oaDZTDeq/4c5J545E75Lg7uiwznIM/P5W4hTYFSiYIwVjJtzJ68Wv81f1nv65PNhfhupvVrNHUIYLEsqmhAynzhS6vOOboqo+u3p6DriEo9zEz/ftPSb8GrICuP3OE= 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 BN6PR04MB3730.namprd04.prod.outlook.com (2603:10b6:404:d6::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Thu, 2 Sep 2021 13:01:04 +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.020; Thu, 2 Sep 2021 13:01:04 +0000 Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? To: cygwin-developers@cygwin.com References: <20210901080220.ee4a5bfbea62cc1ae0a9598e@nifty.ne.jp> <20210901091652.6bf3cccbcaed4a22f6ffa6b0@nifty.ne.jp> <20210901172339.1039604b7067e0492534a20f@nifty.ne.jp> <24138e20-aa97-cfea-bf48-198fc67755ea@cornell.edu> <9ba687eb-f4a0-18f8-b10b-76e7e51e123e@cornell.edu> From: Ken Brown Message-ID: <152bfc0c-2f72-c684-6fc5-aa7c36c136b8@cornell.edu> Date: Thu, 2 Sep 2021 09:01:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH2PR18CA0030.namprd18.prod.outlook.com (2603:10b6:610:4f::40) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) MIME-Version: 1.0 Received: from [IPv6:2603:7081:7e3f:3419:dd6:ee3e:5092:8b08] (2603:7081:7e3f:3419:dd6:ee3e:5092:8b08) by CH2PR18CA0030.namprd18.prod.outlook.com (2603:10b6:610:4f::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Thu, 2 Sep 2021 13:01:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa5ed065-5f98-408d-87ea-08d96e11b8de X-MS-TrafficTypeDiagnostic: BN6PR04MB3730: 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: ItkLBTqzcTxcTiGnJh2qA1vzWEA6kMzpKzBaK+oKrQfui3zDeEzEuREszp1D1lC3Kr47e3Dhy3H+rVq+yOikedd2e/JW0Crn8W9om3wm2SfOlJG8jBWCGm+eYALiPPY8fPG2rMTSp9j9IKR+9IL8/6fPwCWxdZc2K+bAwv7kgrU36Yt8rPnpSkq/iPXJkLYJJjjxjAQ62/m9SCnHIP/QCxI2csUFz6N3AtgK4syhiB8dLTG1tXTyaGaNij96n2UjdHSUljsm/piOfLPHS9eXXSjvUXJv/DAMKBH9QtjGtcK7SCs2/cb7UNVXO8QEFFua9xOuTo/IsQ6vbR55AH1hZXc89jPmuzHwhSpSmD8R5fMbr4AXqVPA0y/8XNkhwZJI0S5t37HZOdFc3+gmVQL6THp8jjO2S6DDu60UuQm5BFsnUgfOWJ8yTvs1nAmpnB1lso5Hkl1tp6Q1WxwliYnSqwaRnAOBbXkbAof0vv3lVxx4YNbGDmudYstL8zboNu0+Z6EfMR7oJsZWsyHz6AFr9Ozsx51VHP//R3ijYMdCpPdk13CodV8fX/14f3QekQI2MMcujNIUSn4SnqpPPc+YDcW+dk5fyTpPma9AFVjHRG4khAUQ+uO7wDp7mlaTg12ZGwrb9PBQlyG0g1EtAx5qNSgAGRKh988YJvzz8wF95fZYsr7zRSwOrDFRR8ttjfj8rJ3n+2CWnnoP0DhCrdGkh8eXpZhYiTdxa51EfDizpJyy45c7hev2mC9BDi25aE9ymYGyEJFCwmbeJgLnzqxuMogh7wW8J1P0JtfJpqBupXqun8xk1TLcp+3G83fT4Xbn 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)(376002)(346002)(396003)(39860400002)(136003)(366004)(86362001)(53546011)(2616005)(66476007)(6916009)(478600001)(66556008)(75432002)(31686004)(966005)(66946007)(31696002)(2906002)(6486002)(83380400001)(8936002)(5660300002)(8676002)(38100700002)(316002)(186003)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?bxcUnSQ0uqMLYqOAMK4NYhY/Lfr3ywxbEeMD/X6LtYDDk4HcasWAW82Y?= =?Windows-1252?Q?B3p+JRZX8Y2RFcK+WZoroaN3v6/cTebI+je1xAKa3aVJ6iLXJIQQfAtY?= =?Windows-1252?Q?J/tdF5D1jvQg9LhnhHB22MEWWTxgDxge9CNIiES9CwE3mlGbUcepAaoT?= =?Windows-1252?Q?lQSp0cQJIJSQiKHQb+un7b1jm7lzuViFDXCsLWrrEKxw+nyWvojb4POG?= =?Windows-1252?Q?bJ539IsRNb7mjiUMVK8YdDU/QCLnrUXSHmoxzXhG7/48kzg4Zzi/piBs?= =?Windows-1252?Q?ZIWvu6SegIm/r5sMuCFiF+3rqOZeuo4mgv9mYbgTbRGv375TQkLyLQXQ?= =?Windows-1252?Q?1hSxerHT/58T/b2L538NRqnzrWl7MRROhsGtrAdtCtFBPygFyMxldWhC?= =?Windows-1252?Q?pnB4aPhROR24OFnCfWNj0NkheZyC6tHO9+8/z6j6Ulo7KAN4ijPEptdZ?= =?Windows-1252?Q?CAaY0O/6hir35m2zJzRj2He8849mCQwZUfSLehOeFRVhDnqJBRA0W4wZ?= =?Windows-1252?Q?gtGKbJOjF/AG8C94ZzG75nQJl/6JNq0n4YUNblsDGbFiDp8YTR6wCQ9p?= =?Windows-1252?Q?cja0LJ0+YtjK+Glhp43ZpN7iz90BN3nJ4PBfgZhtAlYRMrcl6qW2ijgn?= =?Windows-1252?Q?/wv4V5WfvYgx28FH+9a4kS173XKZ+8vRBZtI7XyjMIyKPwvDEangT4Uc?= =?Windows-1252?Q?RWDi8MSzOzeXXG7VKMlwZa7oxIKGC6yxtrXOszsthZyviECUZlSazg0l?= =?Windows-1252?Q?hN/2XM8z/N4o5XL8FnbIfxz4H5kSp4WC7bkoyyxongNrIuCYybQRl5Uw?= =?Windows-1252?Q?3rvUuhgEgaQgaDsTM2cSBi4S5dG12+MYkK0r3Q2qfT3ddWIkju2lS/af?= =?Windows-1252?Q?Yf1ozpxgT1D3r3c1+IxfSxNp0k0wQ3n/506hb9AdzQI3liPPlK0b61Z/?= =?Windows-1252?Q?zEdpfn3c36M0m1A553SH98dQvDl9MMTRvMhdbKz+oAhuqbQsESZTRHyX?= =?Windows-1252?Q?KizTnZ/oesNAZbdxGvcV6S/8iaElzlotnYkSYII8rkL1u9JGQqNd41yE?= =?Windows-1252?Q?UHC6APU9BWWm6XiHaK7+XIV+n6sgVCpOrYIOh3MQyU4mvaW8mALXuFyU?= =?Windows-1252?Q?Xu2neXoAt/OOBOsVIJjnzuXBaSolP910Tfcxolm7tyPfb0vz9ZKV8u0N?= =?Windows-1252?Q?kx4eQrrIV70X8suLQ52CU7Lk/swMJ7fxmZGv/d5he1rE0r3QFQtuGQps?= =?Windows-1252?Q?XjvGPplGqEsdcfxi0X6orMttQ6wnjth/dO1b0D8rFZUJAcY13XALqYGx?= =?Windows-1252?Q?Anu1KA3a8yeeI4fBl0o6tSKYkYnkma3FoEJWSxj/4A7juuUFEiQ0IQgj?= =?Windows-1252?Q?EsB81Tuw+c48SVYS86Jz4k3jxjCv6M+04KLyteSWfJ0NqlrE+o5D9DzV?= =?Windows-1252?Q?dW7Ya+53o/SMc58iKXmLCgO4en4rippozBja5dEfbzRWHrTobbludyyf?= =?Windows-1252?Q?B4VdGnyC?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: fa5ed065-5f98-408d-87ea-08d96e11b8de X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2021 13:01:04.7325 (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: LBbwnTuQ++gSbUdofzargVuumyfBDndKKacUP9LGOTyzSqaY1syDAYGNu/WNWuNElIHJF9131bIMcC/BGjZVJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB3730 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Thu, 02 Sep 2021 13:01:21 -0000 On 9/2/2021 4:17 AM, Corinna Vinschen wrote: > On Sep 1 19:02, Ken Brown wrote: >> On 9/1/2021 9:52 AM, Corinna Vinschen wrote: >>> Great idea that. What we need would be some semaphore upside down. >>> One that can be used to count items and which is signalled if it's >>> down to zero. >> >> Here's an idea (untested), based on https://stackoverflow.com/questions/6559854/is-there-something-opposite-to-semaphore: >> >> We create an ordinary Windows semaphore and use it to count the readers: It >> starts at 0, we increment it by calling ReleaseSemaphore when a reader is >> opened (by fhandler_pipe::create, fork/exec, dup), and we decrement it by >> calling WFSO when a reader closes. When we decrement it, we test whether >> it's been reduced to 0. We do this by calling ReleaseSemaphore and using >> its lpPreviousCount argument. >> >> We also create an event that we can use to make WFMO return during a >> blocking write. We signal this event if a reader closes and we've >> discovered that there are no more readers. In this case we cancel the >> pending write [*] and return an error. >> >> I'm sure I've overlooked something, but does this seem feasible? > > It could work, but the problem with all these approaches is that they > are tricky and bound to fail as soon as a process is killed or crashes. > >> [*] I don't know offhand if Windows provides a way to cancel a pending >> write. If not, we could use query_hdl to drain the pipe. > > There's a CancelIoEx function to cancel all async IO on a handle. > > In a lucid moment tonight, I had another idea. > > First of all, scratch my patch. Also, revert select to check only > for WriteQuotaAvailable. > > Next, for sanity, let's assume that non-blocking reads don't change > WriteQuotaAvailable. So the only important case is the blocking read, > which reduces WriteQuotaAvailable by the number of requested bytes. > > Next, fact is, we're only interested in WriteQuotaAvailable > 0. > And we have a buffersize of 64K. > > We can also safely assume that we only have a very small number of > readers, typically only one. > > So here's the crazily simple idea: > > What if the readers never request more than, say, 50 or even 25% of the > available buffer space? Our buffer is 64K and there's no guarantee that > any read > PIPE_BUF (== 4K) is atomic anyway. This can work without > having to check the other side of the pipe. Something like this, > ignoring border cases: > > pipe::create() > { > [...] > mutex = CreateMutex(); > } > > pipe::raw_read(char *buf, size_t num_requested) > { > if (blocking) > { > WFSO(mutex); > NtQueryInformationFile(FilePipeLocalInformation); > if (!fpli.ReadDataAvailable > && num_requested > fpli.InboundQuota / 4) > num_requested = fpli.InboundQuota / 4; > NtReadFile(pipe, buf, num_requested); > ReleaseMutex(mutex); > } > } > > It's not entirely foolproof, but it should fix 99% of the cases. I like it! Do you think there's anything we can or should do to avoid a deadlock in the rare cases where this fails? The only thing I can think of immediately is to always impose a timeout if select is called with infinite timeout on the write side of a pipe, after which we report that the pipe is write ready. After all, we've lived since 2008 with a bug that caused select to *always* report write ready. Alternatively, we could just wait and see if there's an actual use case in which someone encounters a deadlock. Ken