This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] NUMA spinlock [BZ #23962]
On Tue, Jan 15, 2019 at 01:36:56PM +0100, Torvald Riegel wrote:
> > 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.
>
> Note that I'm not advocating for focusing on just the adaptive mutex type.
> IMO, adding this type was a mistake because whether to spin or not does not
> affect semantics of the mutexes. Performance hints shouldn't be done via a
> mutex' type, and all mutex implementations should consider to spin at least
> a little.
Strongly agreed that this was a mistake. This same sentiment is why I
don't like the nomenclature "NUMA spinlock". If there are semantic
differences from a normal spinlock, it should be named for the
semantics, not for the form of extreme performance tuning it does. If
there are no semantic differences, NUMA-optimized spinlock
implementation should just be a drop-in replacement for the standard
spinlock API.
Rich