This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] NUMA spinlock [BZ #23962]
>> "Scalable spinlock" is something of an oxymoron.
>
> No, that's not true at all. Most high-performance shared-memory
> synchronization constructs (on typical HW we have today) will do some kind
> of spinning (and back-off), and there's nothing wrong about it. This can
> scale very well.
>
>> Spinlocks are for
>> situations where contention is extremely rare,
>
> No, the question is rather whether the program needs blocking through the
> OS (for performance, or for semantics such as PI) or not. Energy may be
> another factor. For example, glibc's current mutexes don't scale well on
> short critical because there's not enough spinning being done.
>
yes. That's why we need pthread.mutex.spin_count tunable interface before.
But, that's not enough. When tunable is not the bottleneck, the simple busy-waiting
algorithm of current adaptive mutex is the major negative factor which degrades mutex
performance. That's why I proposed to use MCS-based spinning-waiting algorithm for adaptive
mutex.
https://sourceware.org/ml/libc-alpha/2019-01/msg00279.html
Also, if with very small critical section in the worklad, this new type of mutex
with GNU extension PTHREAD_MUTEX_QUEUESPINNER_NP acts like MCS-spinlock, and performs
much better than original spinlock.
So, in some day, if adaptive mutex is tuned good enough, it should act like
mcs-spinlock (or NUMA spinlock) if workload has small critical section, and
performs like normal mutex if the critical section is too big to spinning-wait.