Re: nptl 0.60

So this was the kernel requeue stuff that explained my condvar lockups on my
SMP machine ?

Could you please give me a pointer to any info on this problem ?

Right now, the lll_futex_wake (futex, 1) done in __pthread_cond_signal() is
problematic, because it wakeups the awaiting thread that is usually made
'onproc' and has to re-enter another sleep state because of the
cond->__data.__lock being locked by the first thread.
Thats 3 system calls overhead and 2 thread switches.

Eric Dumazet

> The changes include:
>
> ~ deadlock fix in condvar.
>
> ~ possible lifelock fix in all code using the locking primitives.
>   This doesn't happen on UP machines, can happen rarely on small
>   SMP machines, and increases dramatically with every added processor.
>
>   The result of fixing this is, for instance, that the Volano Java
>   thread benchmark runs 8 times faster.  This is a dramatic case but
>   noteworthy.  Other tests improve less and some applications experience
>   a slight slowdown (compared to previous NPTL version).  This slowdown
>   cannot be avoided, we need a more expensive operation to implement
>   the locking.
>
> ~ the s390 port now uses the generic code.  No more specific functions
>   with the funky asms.
>
>
> The Alpha and SH ports still need to be adjusted for the locking change.
>  All the others Jakub and I tool care of.
>
>
> Let me know whether this code works.  Fixing this performance problem
> (and the lockup) was the last item on my list and I want the people who
> complain about "exprimental" software due to < 1.0 version number of my
> back.  If I don't hear negative reports I'll make a 1.0 release soon.
>
> -- 
> --------------.                        ,-.            444 Castro Street
> Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
> Red Hat         `--' drepper at redhat.com `---------------------------
>
>
> -- 
> Phil-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/phil-list
>