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

[Takashi Yano]

On Mon, 30 Aug 2021 22:14:15 +0200
Corinna Vinschen wrote:
> Hi Ken, Hi Takashi,
> 
> On Aug 30 19:00, Corinna Vinschen wrote:
> > Ok, let's discuss this.  I added more code to my testcase and here's
> > what I see.  I dropped all data from the output which doesn't change.
> > [...]
> > - InboundQuota and OutboundQuota are always constant values and
> >   do not depend on the side the information has been queried on.
> >   That certainly makes sense.
> > 
> > - WriteQuotaAvailable does not depend on the OutboundQuota, but on
> >   the InboundQuota, and very likely on the InboundQuota of the read
> >   side.  The OutboundQuota *probably* only makes sense when using
> >   named pipes with remote clients, which we never do anyway.
> > 
> > The preceeding output shows that ReadDataAvailable on the read side and
> > WriteQuotaAvailable on the write side are connected.  If we write 20
> > bytes, ReadDataAvailable is incremented by 20 and WriteQuotaAvailable is
> > decremented by 20.
> > 
> > So: write.WriteQuotaAvailable == InboundQuota - read.ReadDataAvailable.
> > 
> > Except when a ReadFile is pending on the read side.  It's as if the
> > running ReadFile already reserved write quota.  So the write side
> > WriteQuotaAvailable is the number of bytes we can write without blocking,
> > after all pending ReadFiles have been satisfied.
> > 
> > Unfortunately that doesn't really make sense when looked at it from the
> > user space.
> > 
> > What that means in the first place is that WriteQuotaAvailable on the
> > write side is unreliable.  What we really need is InboundQuota -
> > read.ReadDataAvailable.  The problem with that is that the write side
> > usually has no access to the read side of the pipe.
> > 
> > Long story short, I have no idea how to fix that ATM.
> 
> 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.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>