From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e89::72c]) by sourceware.org (Postfix) with ESMTPS id 7D2793858402 for ; Mon, 13 Sep 2021 17:42:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D2793858402 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=Dnxw0GGwieZ7w/QCxIOp90hIhe9hThShM4HamGsC5zAax4qesl3d7MsXSG+4IW5Akz/VK4inBPZMOKDpGX2VWykV50JQgwC/LSkqq9l9rqXkGso1HG7gFgai0UhuhJWQ46xEFTn6oGdP8da6WjOhMz3tFsZcv5/1+jTpiSVVFw5U1mrL/IOGiI6hsrWXLDfKBnMlvPgD6YsIgJtVrLFgrQIzyVszQ63SMO6g0ve/9AJx3oj0WPSjlHloL1Pp4qkJtf1WPuruVzBPAfWnP/W02r2O306T06g8fPYZcf+dV0fw8U1+b/+7fEFgT+3wze0ocLyx3RvyTI1SxzJD6cOsZA== 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=7LtPRXYHGASHtyfG2wVa5UIYjq6Q7GMBpgwGEPUyBdo=; b=kEKX2Kg2ga3GVJVj/EEXbXtn0j/LDTZCl1TEut2CDjBayBeTYeX5OGlTHV/YvUPCm5mlc02Vtq7KqL3S/QvHdUVGvrxM2KOvUN/08EXOu6dREGKGu5kBkwJhk5u3jf7c0MsF6XZxFoHpEuynymkrIFWAGJU5vu48hBGWHwKlx23Zhuv1IBTq1Nz2cOHrxHRgLG0vt1f08Qv7nB84yxXQAcjXyrTfJYIjfeORlsKABuJ/msihnCGMnzx03Xsx6yYB+57ZdUB+KT6xVme824LY3QzHfsEikC82tYYLP2k2b1lkKfOsetLgJj3r6XVaNeDVqZrn/x/PFg4jbE+adCA8qA== 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=7LtPRXYHGASHtyfG2wVa5UIYjq6Q7GMBpgwGEPUyBdo=; b=FiTeQ1ob2tPfzYIUsUInW8m4uROW/sw7w4ojByZmS9Cm/8ydIiW6/efYOljK+8dqd65de3KoVqwQiU8coENsh01/U2fIFFOI68WVnMmq/d4zhKv9NHG6OdkYUE0VEfQglMoipfmoidHrdOvd4pG15Qcm1LIFLZftQJgaj9cy02E= 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 BN8PR04MB5716.namprd04.prod.outlook.com (2603:10b6:408:a0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.17; Mon, 13 Sep 2021 17:42:48 +0000 Received: from BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::5113:e84a:b38a:7a66]) by BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::5113:e84a:b38a:7a66%6]) with mapi id 15.20.4500.019; Mon, 13 Sep 2021 17:42:48 +0000 Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? To: cygwin-developers@cygwin.com References: <41A583E1-C8E7-42AB-9F24-EEC33A41EC60@house.org> <20210826062934.54f2f2216021c095bb7ba13b@nifty.ne.jp> <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu> <20210827202440.47706fc2fc07c5e9a1bc0047@nifty.ne.jp> <20210907122631.65452be8d021ec72259431d5@nifty.ne.jp> <20210909124115.555c6be15d675500617d284a@nifty.ne.jp> <20210909170549.506cc3c1f6029d904fece6dd@nifty.ne.jp> <20210909211940.51ef391e27d43f0421962cb8@nifty.ne.jp> <20210909214246.cd1ff1a3062fea27e51ad4ae@nifty.ne.jp> <33386baf-3b2d-d57f-2ad3-1bd328ed7935@cornell.edu> <20210911075734.aaf37697ba7db2ad14d911a3@nifty.ne.jp> <20210911113517.f74fc3ac1971bbf04c7a9bd1@nifty.ne.jp> <695ce1f4-4f7d-f3f3-6dd3-087467d67b28@cornell.edu> <20210912174849.3d38107568065a95aeb19c7c@nifty.ne.jp> <20210912200423.667e40eb1adc52461bbefa20@nifty.ne.jp> From: Ken Brown Message-ID: Date: Mon, 13 Sep 2021 13:42:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <20210912200423.667e40eb1adc52461bbefa20@nifty.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH0PR03CA0321.namprd03.prod.outlook.com (2603:10b6:610:118::17) 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 CH0PR03CA0321.namprd03.prod.outlook.com (2603:10b6:610:118::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Mon, 13 Sep 2021 17:42:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c9dc620-27cb-4f42-a2f8-08d976dde699 X-MS-TrafficTypeDiagnostic: BN8PR04MB5716: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: C543h6KIZfjBK0k1+0k5yGGnuHjo5NimwCNl8PIncP6kmUDmFB/B4t7aZvGOjHWSB2FCKddo/8VqQl6rV4916sgOoVDXAy9t+JB4QwYX/5DJSFSiNHl/VZ2emRjwhbnZZdebZ489NSTyDllbzcUvn0gVcBMX3sdW3wEsczzA2kXR31EtYwz50H+K6URrXZHTmo01uKVvJgp4z+X+o63o450BcVDyoYP+9Nl2sf5SnmQuNVv+6d1ka8koqLNg0r/e3vHqJrzzLqui7S+CFF37oCVduczkoCo5RyXoKJxZ+4bmrb+wWxxCxCxYuEPZkDQBSKfZ0ZDhxfKS81RF/IXYChsmMINxLtKBWAlWT9twm4za9F2sl+j4Kva+539TOh/q+aCvQmL+kvViguA898GNT2hU+HYf/J/JwI1MelN45Lf4V9MVbIT5/lKM5YbSg2CczlURVaoIN+Is4VZq8xqGz6E8jA04r8KVx20bRd1XLqh6hYrWDSxxbymIX2oMWXQVh4/MFWg5v8wCF73gr75oqv9T/2MxBFoonkc+SLlVFyW+a8yIeYwsRwIviARzFdevKTSiwOCf1GdKMLrZmzoDu5YRihGXrf+0pFzfJolY+P2IhAPNTw5LOHFXNZRpl9LYCLitROwxYq6DwFlClpElNQwgz++W9kdU2otyGB8ZrB4T7Pe7mfrfuyCq9ebQv45wSBue/lVdEODkd1xqqUN+Rzla2R68+UFXLMBS0gnqMT7pt5gEScqhkW+D6o6iQjkq 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)(136003)(396003)(366004)(39860400002)(376002)(346002)(956004)(6486002)(2616005)(8676002)(75432002)(16576012)(316002)(83380400001)(478600001)(31686004)(38100700002)(36756003)(86362001)(5660300002)(6916009)(31696002)(8936002)(66476007)(53546011)(186003)(2906002)(66556008)(26005)(66946007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?C7JmOYNhwABXrQxCUGLCEDa8Y0rTvXVDKDTxtiNL89/o3OsQl2cFbZBb?= =?Windows-1252?Q?aoDojCTslVWVnPYKZdyEyafw4JID96yWpXCEKeKSqhwwN8HX8vgasziB?= =?Windows-1252?Q?lTJzL4J38DLYurBPaRSNWNNsjDkT5mjt+wy4Xeh3pv6xqfhZsm0ha/qi?= =?Windows-1252?Q?h6H9bo7twVfqlCcgjGTrDnCAbbdhYScqDrmFk4Qv+5pW0p+EevytaG+w?= =?Windows-1252?Q?YUDJF884YAiniE1JffcqSSQIpZwporWgfAA28JGGXn1hk6E0oiLzRejJ?= =?Windows-1252?Q?UgNJl0HT4rPrbtRtG/gznjWdf/GDC5tEzTC1Map2S3T1+AxK+WFJsjux?= =?Windows-1252?Q?V1PF1ZB2n2GbmjISNQSkH1/4JcFwjKtt/Y5P782RmmLi5s5LSTN6UD4t?= =?Windows-1252?Q?245b5svl7eVu6XodQ5GnzEMRInR5hkuNW+pUP1A6sazRX3eNLjz4dM3x?= =?Windows-1252?Q?uBjtCspyTG7ruRX52JZEmnEjJVL7+jhH7O+YQp6DAFVCoLnWAAlE+f50?= =?Windows-1252?Q?j1i4tykn4eX8pVdRFVIZ42QrvHOIsYE4M2EKwdPqwfKkUZpAijse5Ly9?= =?Windows-1252?Q?PUg6x7MmEReB7LiHJfVzsZXKDynayd+bB3Wuoc5bURKYe1iMEYgZAiwm?= =?Windows-1252?Q?xSBtxnOzQJJIet0GIJUVLc45KT/Qf9R0u4XXZcqBr0/aaKRA5a6ThL7z?= =?Windows-1252?Q?0GhGpwLRZBGUY/TBOB9yU7F4MHPgy8dxutfKT7FMS0pPNBGt6gQUiHRC?= =?Windows-1252?Q?TGy4fwx7k4GBxuG8v3/qRLeqaIQibWOwiGnPtC28OSqoGo6n7eUu1wkO?= =?Windows-1252?Q?DEdyl8L9TMiUiBe9U+TlSSGsIDWnPMSpbkHn2ayX+oJaTAT0ogYvL6zn?= =?Windows-1252?Q?Dht7WnTC4jBcw40M5ONZbzKvfKm0ZcZw88QLKOKt67TYf8/frblDtpAj?= =?Windows-1252?Q?bI7EZNBRDcJRYYLdIJGucL4BprWi/NQr/Ah6P0kOB/gFShTqdDOk28E+?= =?Windows-1252?Q?JXiGy3fpKSiLXsUYVX1019KLlyw1WXGp7J5Ur44Z1teSUiGiCJCTh5Aq?= =?Windows-1252?Q?pjl0D+5h2o00y99ak/4309tjI/yBcqSiq09s5KLR7pf+XV797TXr/EF9?= =?Windows-1252?Q?xdSDzVC5FXTjVxems5sLFDcKh8Y7jImcDBn/9i2/WRezv+40hc0hvovQ?= =?Windows-1252?Q?kPOgC53lAg7cxyIJsdhyvsGHkSYMCdO2FcSFYK02DJNuuHPfgRklSra6?= =?Windows-1252?Q?gQwZadNBrAiB9yL7SfY30wNc7qe3RrkLA/ShqsFDe0jHowcwOlyr5LIs?= =?Windows-1252?Q?p0ugG5mUC8tniCMOoLRqzISNfY3Yx6BxYlyxTRWwk3Aa6I8twJ9G0j+w?= =?Windows-1252?Q?nd+mX0+cJOmWReqIsMzMOHr/fiRWD/jz1Ah0tBpzWpBzcCXAo9+gJeo8?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 8c9dc620-27cb-4f42-a2f8-08d976dde699 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2021 17:42:47.9343 (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: scRYxmHMEUtoKJF04FlWOTldfTF6GqqRV/7DUNnJAzWk6aN15RrR5kh89/J+bNDJW4U/paecFJyNADmxmi4vuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5716 X-Spam-Status: No, score=-10.7 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, 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: Mon, 13 Sep 2021 17:42:52 -0000 On 9/12/2021 7:04 AM, Takashi Yano wrote: > On Sun, 12 Sep 2021 17:48:49 +0900 > Takashi Yano wrote: >> Hmm. Then, what about PoC code attached? This returns to Corinna's >> query_hdl, and counts read/write handles to detect closing reader side. >> >> If the number of read handles is equal to number of write handles, >> only the pairs of write handle and query_hdl are alive. So, read pipe >> supposed to be closed. >> >> This patch depends another patch I posted a few hours ago. > > Revised a bit. A few small comments/questions: > diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h > index 13fba9a14..f09af2c37 100644 > --- a/winsup/cygwin/fhandler.h > +++ b/winsup/cygwin/fhandler.h > @@ -1176,10 +1176,15 @@ class fhandler_pipe_fifo: public fhandler_base > { > protected: > size_t pipe_buf_size; > + HANDLE query_hdl; > > public: > fhandler_pipe_fifo (); > > + HANDLE get_query_handle () const { return query_hdl; } > + void close_query_handle () { CloseHandle (query_hdl); query_hdl = NULL; } Should you use if(query_hdl) here? Or is it up to the caller to check that? > @@ -522,6 +532,10 @@ fhandler_pipe::fixup_after_fork (HANDLE parent) > fork_fixup (parent, read_mtx, "read_mtx"); > if (select_sem) > fork_fixup (parent, select_sem, "select_sem"); > + /* Do not duplicate query_hdl if it has been already inherited. */ > + if (query_hdl && !get_obj_handle_count (query_hdl)) > + fork_fixup (parent, query_hdl, "query_hdl"); Why do you need to call get_obj_handle_count here? Shouldn't fork_fixup take care of the case where the handle has been inherited? > @@ -608,12 +608,43 @@ pipe_data_available (int fd, fhandler_base *fh, HANDLE h, bool writing) > } > if (writing) > { > - /* WriteQuotaAvailable is decremented by the number of bytes requested > - by a blocking reader on the other side of the pipe. Cygwin readers > - are serialized and never request a number of bytes equivalent to the > - full buffer size. So WriteQuotaAvailable is 0 only if either the > - read buffer on the other side is really full, or if we have non-Cygwin > - readers. */ > + /* If there is anything available in the pipe buffer then signal > + that. This means that a pipe could still block since you could > + be trying to write more to the pipe than is available in the > + buffer but that is the hazard of select(). > + > + Note that WriteQuotaAvailable is unreliable. > + > + Usually WriteQuotaAvailable on the write side reflects the space > + available in the inbound buffer on the read side. However, if a > + pipe read is currently pending, WriteQuotaAvailable on the write side > + is decremented by the number of bytes the read side is requesting. > + So it's possible (even likely) that WriteQuotaAvailable is 0, even > + if the inbound buffer on the read side is not full. This can lead to > + a deadlock situation: The reader is waiting for data, but select > + on the writer side assumes that no space is available in the read > + side inbound buffer. > + > + Consequentially, the only reliable information is available on the > + read side, so fetch info from the read side via the pipe-specific > + query handle. Use fpli.WriteQuotaAvailable as storage for the actual > + interesting value, which is the OutboundQuote on the write side, I thought Corinna's experiments showed that InboundQuota and OutboundQuota are the same on the read and write sides, and that InboundQuota is the one we should be using. Ken