cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Corinna Vinschen]

On Aug 30 09:41, Ken Brown wrote:
> On 8/30/2021 9:20 AM, Corinna Vinschen wrote:
> > On Aug 30 15:00, Corinna Vinschen wrote:
> > > On Aug 30 10:27, Corinna Vinschen wrote:
> > > > [Moving discussion to cygwin-developers]
> > > > 
> > > > On Aug 29 11:57, Ken Brown via Cygwin wrote:
> > > > > Corinna, do you still see any benefit to switching to PIPE_NOWAIT?  AFAICT,
> > > > > it wouldn't decrease the code size at this point, so the only question is
> > > > > whether it might improve performance.
> > > > 
> > > > Pipes are already using PIPE_NOWAIT aka FILE_PIPE_COMPLETE_OPERATION
> > > > mode, see set_pipe_non_blocking.  The problem is that it's not used for
> > > > blocking pipes.  Rather, blocking pipes use overlapped IO.  Overlapped
> > > > IO is conceptually upside-down from the POSIX concept of non-blocking.
> > > > Also, the information returned in FilePipeLocalInformation is historically
> > > > borderline.  For kicks, see
> > > > https://cygwin.com/pipermail/cygwin-patches/2004q4/005002.html
> > > > 
> > > > So my suggestion is to try switching to non-blocking Windows pipes
> > > > entirely, even for blocking pipes on the user level.  It works nicely
> > > > for sockets.
> > > 
> > > On second thought, I'm not so sure how to block on non-blocking pipes
> > > on writing.  Assuming a write fails because the buffer is full, we
> > > don't have a waitable object to wait on.  Unless the pipe handle is
> > > signalled if writing is allowed, but that would be a first in Windows.
> > > So in theory this would still require overlapped IO.  Does that still
> > > work as desired if the pipe mode is non-blocking?  I don't think I ever
> > > tried that...
> > 
> > That probably doesn't make sense.  If WriteFile returns without writing
> > something, what should overlapped io be waiting on?
> 
> The approach I've taken on the topic/pipe branch is to stop using overlapped
> I/O and to always keep the blocking mode of the Windows pipe in sync with
> the blocking mode of the fhandler.  This seems to work pretty well so far,
> although problems could certainly show up after further testing.

Erm... afaics, fhandler_pipe::raw_read and fhandler_pipe::raw_write are
still using overlapped IO on blocking sockets.  Otherwise, how'd you
handle signals?

Just to be clear, Windows pipes can be read/write in three modes:

- non-blocking	 (FILE_PIPE_COMPLETE_OPERATION)
- synchronous	 (FILE_PIPE_QUEUE_OPERATION, non-overlapped)
- asynchronous   (FILE_PIPE_QUEUE_OPERATION, overlapped)

Right now the pipe code uses non-blocking mode for non-blocking sockets
and asynchronous mode for blocking sockets.  This looks like the most
promising approach, afaics.


Corinna