Re: [PATCH] NUMA spinlock [BZ #23962]

[Carlos O'Donell <carlos@redhat.com>]

On 1/7/19 2:48 PM, H.J. Lu wrote:
> On Mon, Jan 7, 2019 at 11:12 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>>> Should glibc have scalable spinlock, in libc.so or a separate shared object?
>>> Or should we tell people that if they want scalable spinlock, they look
>>> elsewhere?
>>
>> I think non-polymorphic, small lock types with scoped locking could make
>> sense for glibc.
>>
>> A lock specific to a certain machine architecture seems strange.  We
>> currently lack any of the kernel NUMA interfaces in glibc, which makes
>> this stand out even more.
>>
> 
> And this lack of support doesn't make problems to go away.
 
No. But it is a strong indicator that the solution space hasn't been
explored thoroughly enough for us to provide a long-term stable interface
that will remain useful.

My opinion is that for the health and evolution of a NUMA-aware spinlock
and MCS lock, that we should create a distinct project and library that
should have those locks, and then work to put them into downstream
distributions. This will support key users being able to use supported
versions of those libraries, and give the needed feedback about the API
and the performance. It may take 1-2 years to get that feedback and every
piece of feedback will improve the final API/ABI we put into glibc or
even into the next ISO C standard as pat of the C thread interface.

My objection to the NUMA-aware spinlock API is because I feel we are doing
a disservice to the work by formalizing it and freezing it as part of the
ABI/API that glibc is using.

In fact this NUMA-aware discussion touches on a deeply complex issue,
which is: How do we create/design, and evolve interfaces that we want
to one-day have in stable glibc? But this is a discussion for another
thread. Roland once said he wished we had put every function into it's
own library ;-)

Does this explain in more detail why I don't think it's a good idea to
put these interfaces into glibc?

-- 
Cheers,
Carlos.