Re: condvar wakeups

On Sat, 3 May 2003, Ulrich Drepper wrote:

>              LT                old NPTL          requeue NPTL
> 
> minimum:     0.617428174 sec   0.270278439 sec   0.321956284 sec
> maximum:     0.621202585 sec   0.305812929 sec   0.327252124 sec
> average:     0.619208118 sec   0.290176436 sec   0.324108123 sec
> 
> Adding the -k parameter hardly changes the numbers.  On a UP P4 HT
> machine I get for the same configuration:
> 
>              LT                old NPTL          requeue NPTL
> 
> minimum:     1.129867247 sec   0.303806986 sec   0.359285587 sec
> maximum:     1.353488790 sec   0.312475095 sec   0.366070266 sec
> average:     1.229651937 sec   0.306981890 sec   0.361971481 sec
> 
> 
> Needless to say I wasn't expecting the slowdown.  But it is also
> noteworthy that even with 100 threads the LT code never comes even close
> to the performance of NPTL.  This validates what I wrote before, the
> paramwu.c program is really useless as a benchmark.

the thing i suspect currently is that the 'mass wakeup' is handled by the
O(1) scheduler quite well and doing the extra FUTEX_REQUEUE just adds
overhead. The O(1) scheduler itself does something very similar to what
FUTEX_REQUEUE does, just more efficiently. Ie. with FUTEX_REQUEUE we've
traded a mass-wakeup of N threads for a mass-requeue plus N*wakeup. This
explains the overhead.

until someone can show some real degradation due to wakeup behavior i'll
close this issue and wont pursue FUTEX_REQUEUE upstream, it seems to bring
no benefits.

FUTEX_WAKE_NORESCHED is another issue - does anyone have some testcode
that shows the extra reschedules caused by a futex wakeup with an internal
lock held?

	Ingo