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

[Takashi Yano]

On Wed, 8 Sep 2021 11:26:21 +0200
Corinna Vinschen wrote:
> On Sep  8 11:01, Corinna Vinschen wrote:
> > On Sep  8 13:11, Takashi Yano wrote:
> > > On Wed, 8 Sep 2021 09:07:48 +0900
> > > Takashi Yano wrote:
> > > > On Tue, 7 Sep 2021 19:50:23 +0900
> > > > Takashi Yano wrote:
> > > > 
> > > > > @@ -796,7 +792,8 @@ pipe_cleanup (select_record *, select_stuff *stuff)
> > > > >        pi->stop_thread = true;
> > > > >        SetEvent (pi->bye);
> > > >          ~~~~~~~~~~~~~~~~~~~
> > > > This is not correct. SetEvent() wakes-up one of thread_pipe()s,
> > > > but it may be other thread than one which should be stopped.
> > > > 
> > > > >        pi->thread->detach ();
> > > > > -      CloseHandle (pi->bye);
> > > > > +      if (me->fh->get_select_evt () == NULL)
> > > > > +	CloseHandle (pi->bye);
> > > > >      }
> > > > >    delete pi;
> > > > >    stuff->device_specific_pipe = NULL;
> > > > 
> > > > I think it also should be
> > > > > +    for (ULONG i = 0; i < get_obj_handle_count (select_evt); i++)
> > > > > +      SetEvent (select_evt);
> > > > 
> > > > Actually I want to use PulseEvent() here if it is not **UNRELIABLE**.
> > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/28648-pulseevent-is-an-unreliable-function
> > > > 
> > > > Does using semaphore object instead of event, and releasing
> > > > resources equal to the number of handles make sense?
> > > 
> > > No it does not. One thread may consume semaphore multiple times....
> > 
> > What exactly is the problem in the code which results in high CPU
> > load?  Can you explain this a bit?  Maybe we need an entirely
> > different approach to avoid that.
> 
> I saw your new patch, but I don't see the problem.  I typed a lot of
> keys in mintty quickly and what happens is that the load of mintty
> goes up to 9% on a 4 CPU system, but only temporarily while typing.
> How do you reproduce the problem?

Did you apply the patch
0001-Cygwin-select-Introduce-select_evt-event-for-pipe.patch
or
0001-Cygwin-select-Introduce-select_sem-semaphore-for-pip.patch
?

With these patch, the problem does not occur. The problem occurs
with the commit dccde0dc.

With my 4 core 8 thread CPU, CPU loads goes up to 12-13 % if
I type keys using key repeat (30cps) after the commit dccde0dc.

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