This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]