From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2131.outbound.protection.outlook.com [40.107.100.131]) by sourceware.org (Postfix) with ESMTPS id 440B53858425 for ; Tue, 31 Aug 2021 12:33:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 440B53858425 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=aRD1y3Fpqalnkw1uXwtEfPO8MRxl7h6xhkHGU7e6oQuGw1Zv9UaLsJx6gPdzTABYzvCxuXl+HIqumbcZcsnZgGtGeixv7n0vr3CnuQJ7sm0lyR2GSCdr6NbCTALPBJ0f4l7XadCvvb1gRoIgGCiOt148X/x7qvclrGPf+jcbEbLYDkojhjqwYRPshR+FPJShz3n1hFSZ6rWsr5iTchTpbSLad5q00txZ6ZO6QH8YACThs/7OFvd9coi+5FHVA441NC49VcTKb+vd/IuLaZs0hG0I7I3kmK8gYFQGctyHf1+iUaJdZwYo/VrJ3GrE4YPzbor3fw9qyWhAHO51e4r/oA== 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=+bWliXZcpYoC1EpWK9bVDjayLjfqsysZ/HzOv16seeQ=; b=FcBtpcjGdbz46koHRqCIBhDYEhQAbEOGvXl6nD9aSP/sr2FhvcAtDbtyZjfOB2yeJe52C8T5iMsoFDAbpMxCwDOySrjQznlC/1lUr+gb0CD4lOgpRKAVUhAZyPdpqCS1Sdos925SJapirN/SRuIirc+xQVaXxHtw3Suc5XPLX8+FCzY9jyTqnA+dbuI9xFN2G1CLBm0ngZE+nolYUfvcH146m55aGE5b/aGuCSsXmaZsc512sSBKTDnxMybcq11r0ysk5SLq5GyWXZpOYhWhL83r2rADaappKbO79KU2o3w/0bZuCic4AhjB1J7sYlsYTEOUoBX12uMZ2zNiFuvn1g== 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=+bWliXZcpYoC1EpWK9bVDjayLjfqsysZ/HzOv16seeQ=; b=YX8+MWW/4eFLxEqSFJJHKH1ik0BgdzMjME5ybo8JKmh0mNqTGXgejTCR0zCJ0lfKuYHuVx03WhGEfcf/WMcpR31YaIxjSMcEpxbSeVkDvgtcUVkqDEK5Px7mDTDVz4K+CUh5dTuwgRk/sq/vbXPqrNAjjb8zDSl5ZzbDErd04wU= 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 BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Tue, 31 Aug 2021 12:33:24 +0000 Received: from BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::38bd:b608:234f:9ec6]) by BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::38bd:b608:234f:9ec6%7]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 12:33:24 +0000 Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? To: cygwin-developers@cygwin.com References: <529d7dd7-d876-ca51-cc1f-e414d3c24f71@cornell.edu> <20210831175534.21edae2356d74a0750c686de@nifty.ne.jp> <20210831182500.4c1c67dae13f51ca68964f63@nifty.ne.jp> <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> From: Ken Brown Message-ID: <583ca127-02e7-6b3c-3732-6478c0f862e3@cornell.edu> Date: Tue, 31 Aug 2021 08:33:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH0PR03CA0331.namprd03.prod.outlook.com (2603:10b6:610:11a::22) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.211] (74.69.128.111) by CH0PR03CA0331.namprd03.prod.outlook.com (2603:10b6:610:11a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20 via Frontend Transport; Tue, 31 Aug 2021 12:33:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ffd9a664-b4f4-4f9e-7522-08d96c7b8673 X-MS-TrafficTypeDiagnostic: BN7PR04MB4388: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3276; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8H1+Y+aEVVZ6g8kxZ8FIMVR80161pUf2ogd+zPVX6lbRfPMYBXdgf4dLkN1sL6eIUlhSq+HvCqgkwp4W06oE0wkvaxzSM5cb/PhNM1lvEh579uoyZvaFQrf8bvyoYIhWttkzTDvF4CuIVUsfNcOeVAnmCSjxyal7vfJ5riv73z5o0gG9RTi4bCcUAmuaKle5kPWoEHjA2YB6E4oyu7uNC8hx6XElEAkTdAtSOsYsfcUgQSyukaY0fu3s7QqAoF5SvrnIqVszSAWolaxrgn0IajY03gstbcC35CyADrD+6rhHEwSdA72DjwogUnHDbSGoPAcWkwvB6kypt0bK3VoM96DEpkHnwppqGuVLdTVLmStf2KZNu7+qnmWlSELX8TVUKZ99K9llJaWe5yvxXJEXqtkT5AfcA6VmfR/FLg7sGUEpR7y7m7uWudIHDVr2wn+qPMdiMTFyQ5TC0Uq3pkd84J7Sd9LIYhIo+PEcXHmjN6CruARTx8IWTATcFbIQC2BGWPRsLpKKKRlFn8qWM0zMy1qsNbRz604xFdprJBns+/ACdBMv/FiV5uxId79PsZDvLu9V5pXOJbB6XkRkLkRPUyoJpWitHS+MUqA3X9SnnrCFEa3t3/S+EXTkrqCffk/fIognoNeJZrrnYFQs8pT4UhDTRtu3ZNN9jC/nuFXWMhsBeCJVho6vkeY5s6MRJowWvBksqYUp7OQYkSuMmtrQhoWkcQymdrZqXbe9xkMA0l0= 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)(396003)(39860400002)(376002)(366004)(136003)(346002)(2906002)(316002)(786003)(31686004)(86362001)(36756003)(5660300002)(2616005)(83380400001)(66476007)(75432002)(956004)(66556008)(66946007)(16576012)(8936002)(478600001)(8676002)(6486002)(53546011)(38100700002)(26005)(6916009)(31696002)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?y4OvvaTopa2mbeW5nxtCb0Mnl/pSY4/hnjZ5MUtiEYIShX4dN93d+CSb?= =?Windows-1252?Q?uHT8HtRDBriR5x+F0cOXwr11GI/Olu75CNs9v8wzxL/PnoH8FMnBrHjo?= =?Windows-1252?Q?q+Z2BUwYVd6EWQqb33XsOHPkokbXnd+ekKyxRbl2CFmUzbwVvSkJZdaI?= =?Windows-1252?Q?70gksHfdVW1YPNGmp8KsKUbtXXeaRcM+cbzJuU0AwA09uwKZ81aGFXZ9?= =?Windows-1252?Q?033Ulcy+GiN4R3prqjKYnxLHYWhG2m0qKUkrnSFwMxLiThz70O7mp5Y2?= =?Windows-1252?Q?y4wfLnhM+vu3XqX90nU2EAqr5cekVpvame6GOa5RCxsb0BKdrnT65LJm?= =?Windows-1252?Q?2tlWj6dkB2mcNHb8eOAFIHt6Xis/VCVNsyEG48M8Ircbdt0e5RmB/dIS?= =?Windows-1252?Q?Qw9M1kKnq30e8yU10JAUmnEsckRX8S1YBKtLfJDWvv5mavho3ZrgzrKR?= =?Windows-1252?Q?8mh5wILoA/rSuIWfJ9YXMKAs+u0RSodnfHmfq4n55B1YmMe/1/XgWRxR?= =?Windows-1252?Q?RGPqnqrpqyDR1wpexyVG2kuwCtHrT82DOy9Vi7EKGAOFAwSZbUfXJiJY?= =?Windows-1252?Q?Hv537JPwjIjSF4x9sRkVF5Z/fFOQWgnNougrBA26Z6daRwRH+GAR+6zY?= =?Windows-1252?Q?fIUEfQHHFHsvH5NnxIcWQCySwqBj78xmGpYA1qmqX9D8MkNA4mrXO7W7?= =?Windows-1252?Q?q5mlhmrKKdkCkcGmNoTi7IIt/jgfkb1tfuXQBjV0P7ebuZ81jYUq/YQ3?= =?Windows-1252?Q?Gdexd+SmwNM0smsPC6/DRe8VEi6eM52e8rQLXhHQ4YUUZniQz3EinfM2?= =?Windows-1252?Q?Vop9+V1wc9lOH3PpvuqXwbLiQ5VA3NnAPlFO8ZPZdh9zgpKgIASN0Z86?= =?Windows-1252?Q?6CYSB3tKoVDmqi25FtF4Zw9PnJRQkzNUxc7rf8BX1Hhh47Eo2aPCkQXR?= =?Windows-1252?Q?tNg0tZ4fOpvNQ4ATMVlD6W8yUY/q8sHyA1EiSMuFQ9jrZPnpz26Netst?= =?Windows-1252?Q?e4xvOBrSUJNBMtcQfGMQByMFPWzN4ao6fYwqHavcMiNMMOErJVwHWUvg?= =?Windows-1252?Q?n4C8ECM2ueZ5AS3vrCdRvXAFZE66KuDtX1ScWUQEL+00wmP+j1F8zXFa?= =?Windows-1252?Q?8mU/572zMm9JDNOgdbN2L93u7B16zjB43ktrtA1gp5qYdFY+XqunZcb7?= =?Windows-1252?Q?UzIdxHaixP7tV9yIbb6ugQh+F5g8yXqoeSP++XX3WeetzdvDDi7KlMvF?= =?Windows-1252?Q?GreyZ/2uswGKmWywRgjVwlbPTfYupkSaNgsp+JaKYw6DlHStIDZ6XSdG?= =?Windows-1252?Q?eAGHp+AAkrpDxcF0BPtbu6obVq4k5RjyqBctiBbDk2VO/AJgrwhUSZeY?= =?Windows-1252?Q?/OfJZCRikTUwrTH5XT3IqVaDinx2+So+smruIP8JB7SJWCf8peOy1DAl?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: ffd9a664-b4f4-4f9e-7522-08d96c7b8673 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2021 12:33:24.4565 (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: m3d9uim0sCuTifxh060RxvhW1Zn5wZ+mVua+er6HpKFvrdABvoBkdnUDufl/TPztVw82j8MQtdNtVdFy+BaDEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR04MB4388 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Tue, 31 Aug 2021 12:33:37 -0000 On 8/31/2021 7:45 AM, Takashi Yano wrote: > On Tue, 31 Aug 2021 12:18:57 +0200 > Corinna Vinschen wrote: >> On Aug 31 12:05, Corinna Vinschen wrote: >>> On Aug 31 18:25, Takashi Yano wrote: >>>> On Tue, 31 Aug 2021 11:08:42 +0200 >>>> Corinna Vinschenwrote: >>>>> On Aug 31 17:55, Takashi Yano wrote: >>>>>> On Mon, 30 Aug 2021 22:14:15 +0200 >>>>>> Corinna Vinschen wrote: >>>>>>> Hi Ken, Hi Takashi, >>>>>>> >>>>>>> On Aug 30 19:00, Corinna Vinschen wrote: >>>>>>> Well, what about keeping a duplicate of the read side handle on the >>>>>>> write side just for calling NtQueryInformationFile? >>>>>>> >>>>>>> Attached is an untested patch, can you have a look if that makes sense? >>>>>>> >>>>>>> Btw., I think I found a bug in the new fhandler_pipe::create. If the >>>>>>> function fails to create the write side fhandler, it deletes the read >>>>>>> side fhandler, but neglects to close the read handle. My patch fixes >>>>>>> that. >>>>>>> >>>>>>> While looking into this I found a problem in fhandler_disk_file in >>>>>>> terms of handle inheritance of the special handle for pread/pwrite. >>>>>>> I already force pushed this onto topic/pipe. >>>>>> >>>>>> I tested your patch attached. Unfortunately, select() does not work >>>>>> as expected for write pipe. Even if the select reports write pipe >>>>>> is available, writing to pipe fails. It seems that your patch fails >>>>>> to detect pipe full. >>>>> >>>>> Bummer. Is that with byte mode pipes or with message mode pipes? If >>>>> the latter, if you try to write more data than available in the buffer, >>>>> it's bound to fail. >>>> >>>> Both message pipe and byte pipe. >>>> >>>>> Did you add debug output to pipe_data_available to see how the >>>>> information looks like? Or do you have a simple, self-contained >>>>> testcase in plain C? >>>> >>>> The test case is attached. If select() works as expected, the program >>>> does not show "r" or "w". However, with your patch, the program prints >>>> many "w" (means write() fails with EAGAIN). >>> >>> Thanks! I found th culprit, but we have another problem. Even if >>> select returns correct info, A write, trying to write more bytes >>> than are available in the buffer, hangs. This shouldn't happen. >>> Still digging... >> >> That's, of course, correct behaviour for pipes in blocking mode. D'oh! >> >> Please try the attached patch on top of topic/pipe. > > Thanks for the new patch. I have confirmed that above issue > is fixed and select() for write pipe seems to work as expected. > > > BTW, I found one minor difference between Linux and this pipe > implementation. > > The test case is attached. The test case uses non-bloking I/O. > If this STC runs on Linux, the result is: > > 1024/1024 > 1740/1740 > 2958/2958 > 5028/5028 > 8547/8547 > 14529/14529 > 24699/24699 > 41988/41988 > 22227/71379 > 65536/121344 > 65536/206284 > Total: 247KB in 0.000612 second, 403517.628166KB/s > > On cygwin 3.2.0, the result is similar to Linux. > > 1024/1024 > 1740/1740 > 2957/2957 > 5026/5026 > 8544/8544 > 14524/14524 > 24690/24690 > 41972/41972 > 65536/71352 > 65536/121298 > 65536/206206 > Total: 290KB in 0.062653 second, 4628.669018KB/s > > > However, on topic/pipe implementation, the result is > > 1024/1024 > 1740/1740 > 2957/2957 > 5026/5026 > 8544/8544 > 14524/14524 > 24690/24690 > -1/41972 > w-1/71352 > w-1/121298 > w-1/206206 > wTotal: 57KB in 0.000330 second, 172989.377845KB/s > > In non-blocking mode, writing more than pipe space will fail with > EAGAIN in this implementation. > > In Linux and cygwin 3.2.0, it seems to write as much as writable. > > Is this difficult to be fixed? Two other remarks: 1. I think query_hdl needs to be initialized in the fhandler_pipe constructor. 2. When the read side of the pipe is non-blocking, there can be no pending reads, so shouldn't we be able to use WriteQuotaAvailable reliably on the write side? (I can't test this at the moment.) This applies in particular to the call to pipe_data_available at the end of peek_fifo, since all fifo readers use non-blocking pipes. Maybe pipe_data-available needs an extra parameter so the caller can specify that WriteQuotaAvailable should be used. Ken