From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by sourceware.org (Postfix) with ESMTPS id C5BED3858429 for ; Mon, 30 Aug 2021 10:20:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C5BED3858429 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MCKSA-1mCMvi0e26-009S7U for ; Mon, 30 Aug 2021 12:20:32 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id C4007A80D72; Mon, 30 Aug 2021 12:20:30 +0200 (CEST) Date: Mon, 30 Aug 2021 12:20:30 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <4f2cb5f3-ce9c-c617-f65f-841a5eca096e@cornell.edu> <20210828022111.91ef5b4ff24f6da9fadb489e@nifty.ne.jp> <20210828184102.f2206a8a9e5fe5cf24bf5e45@nifty.ne.jp> <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp> <20210830091314.f9a2cb71794d0f68cdb5eba7@nifty.ne.jp> <20210830092259.52f7d54fc3fa340738373af4@nifty.ne.jp> <20210830170204.fa91eaf110f310f13b67abc3@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210830170204.fa91eaf110f310f13b67abc3@nifty.ne.jp> X-Provags-ID: V03:K1:k3qsOHfvM4PkWHEvbPNJ/0hjC4VtM0rsFDGFurpDS/vOxn0SGk/ 6qTef/xnV48eIsSoz10oAAi60wi7yVjxEoOyWthfPnJcIMWdEJjq8YN1wZVhOrzN5PvPaRt Fgaij8Cmj2y4Y89QBHa3/OGD321QO2nG+sp0pgZzLI/d1aJBeDoDNGbXDZjB+132CyHPZB5 qjRe3uzJJQGU5KI97kAxg== X-UI-Out-Filterresults: notjunk:1;V03:K0:tG7tExUJPW4=:BHgl3gJsf/ANDc4QNRl3dO znAyTkTrUmeQpDIlOSBEQoWCRI1TuiQ5XvAT7E22QOPbbZN1WuA598JXen1mPKJogluN4ekXz pfjgDkfjoKNa2bWZ9TtFpbFfH/6BClBYWqhHnDvk/8Gynl6KTfSMhm7/Pje5R5YemTCDSjRIz VaD8xKM3rZISk3zHHq34RrbqlsyjzEsd0tucDo+61n6jfKcL7vrmCOryJL4v5XufsOhDHhArK r44hIkGdYjxmVpWhj604JBxr8T0SreEpg87/d1Ll9jyiWpluBnaaUDeyB9uhG+2WoFtoavYPD 3WrlsIhJASipWIctUI7or/nIDiwjU1GkokkW5t9my/krztmCgIDVFTQDklOXrbocdanaS3u6v llhDzqaSWGKhFJ4bDv8t+vsLgXxX9N4E8LKSQDPES513XHiNBVCQ6WlUJth0RBnCM01qxEjpX r5fMxgWg5I+fI0OXjPxxszR6n6aj2g/FhDkobdsVkoMplSk462CAQbCSGXKjHHesN+P64VYuS N6V0vAspJL/hkm/UMJZyQtcGmzntXGLYRsDJBE1h/pYswlEv9yDeVifijdSSH7VTKMjshsuSk yWtnezJWwTVo5hHSW2oMZzLDM49OiuPH9BKRmmG9hP7l4rzzRoQd1UDhWO5lSGgnhio7ZSU3p f6rmhlgmlADZmPTLJs/SJLHrUG/ig3HO4WImFivjaR+kVJnb0p6HWI0B7wY3Maog9kH8rNXe1 U3rtAPtgV8oRbn+a8XKDbHXXaYjBoheCO87UlCtnES4onHoxXvXNLRD8Hvc= X-Spam-Status: No, score=-100.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NEUTRAL, 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, 30 Aug 2021 10:20:44 -0000 [Move discussion to cygwin-developers] On Aug 30 17:02, Takashi Yano via Cygwin wrote: > On Sun, 29 Aug 2021 22:15:29 -0400 > Ken Brown wrote: > > On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote: > > > We have two easy options: > > > 1) Configure the pipe with PIPE_ACCESS_DUPLEX. > > > 2) Use nt_create() again and forget C# program issue. > > > > I vote for 2), but let's see what Corinna thinks. > > BTW. what's wrong if just: > > static int > nt_create (LPSECURITY_ATTRIBUTES sa_ptr, PHANDLE r, PHANDLE w, > DWORD psize, int64_t *unique_id) > { > if (r && w) > { > static volatile ULONG pipe_unique_id; > LONG id = InterlockedIncrement ((LONG *) &pipe_unique_id); > if (unique_id) > *unique_id = ((int64_t) id << 32 | GetCurrentProcessId ()); > if (!CreatePipe (r, w, sa_ptr, psize)) > { > *r = *w = NULL; > return GetLastError (); > } > } > return 0; > } > > ? > > In my environment, I cannot find any defects. > - No performance degradation. > - set_pipe_non_blocking() works for both read and write pipes. > - NtQueryInformationFile() in select() works for both r/w pipes. > - Piping C# program works. > > Is naming the pipe really necessary? It's not, but CreatePipe is doing this anyway. "Anonymous pipes are implemented using a named pipe with a unique name." https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe The reason CreateNamedPipe was used in the first place was that FILE_READ_ATTRIBUTES isn't set by CreatePipe for the write side of the pipe, however, it creates full duplex pipe: https://cygwin.com/pipermail/cygwin-patches/2004q3/004912.html Given the fact that CreatePipe is implemented in terms of NtCreateNamedPipeFile anyway, why should the pipe created with NtCreateNamedPipeFile fail where the pipe created with CreatePipe works? The only reason can be some missing flag, I think. Checking fhandler_pipe.cc::nt_create and comparing that with the default flags for files and other devices, it occurs to me that the SYNCHRONIZE stuff is missing. So, Takashi, what if you call NtCreateNamedPipeFile like this in nt_create: status = NtCreateNamedPipeFile (r, access | SYNCHRONIZE, &attr, &io, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, pipe_type, FILE_PIPE_BYTE_STREAM_MODE, 0, 1, psize, psize, &timeout); Does that fix the above problems, too? Corinna