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

[Corinna Vinschen]

On Sep  3 19:13, Takashi Yano wrote:
> On Fri, 3 Sep 2021 19:00:46 +0900
> Takashi Yano wrote:
> > On Thu, 2 Sep 2021 21:35:21 +0200
> > Corinna Vinschen wrote:
> > > On Sep  2 21:00, Corinna Vinschen wrote:
> > > It's getting too late again.  I drop off for tonight, but I attached
> > > my POC code I have so far.  It also adds the snippets from my previous
> > > patch which fixes stuff Takashi found during testing.  It also fixes
> > > something which looks like a bug in raw_write:
> > > 
> > > -	  ptr = ((char *) ptr) + chunk;
> > > +	  ptr = ((char *) ptr) + nbytes_now;
> > > 
> > > Incrementing ptr by chunk bytes while only nbytes_now have been written
> > > looks incorrect.
> > > 
> > > As for the reader, it makes the # of bytes to read dependent on the
> > > number of reader handles.  I don't know if that's such a bright idea,
> > > but this can be changed easily.
> > > 
> > > Anyway, this runs all my testcases successfully but they are anything
> > > but thorough.
> > > 
> > > Patch relativ to topic/pipe attached.  Would you both mind to take a
> > > scrutinizing look?
> > 
> > Thanks.
> > 
> > Your code seems that read() returns only the partial data even
> > if the pipe stil has more data. Is this by design?
> > 
> > This happes in both blocking and non-blocking case.
> 
> The patch attached seems to fix the issue.

I'm sorry, but I don't see what your patch is supposed to do in the
first place.  What I see is that it now calls NtQueryInformationFile
even in the non-blocking case, which is not supposed to happen.

I'm a bit puzzled what the actual bug is.

The code changing len is only called if there's no data in the pipe.
In that case we only request a partial buffer so as not to block
the writer on select.

If there *is* data in the pipe, it will just go straight to the
NtReadFile code without changing len.

Where's the mistake?


Thanks,
Corinna