On Sun, Apr 3, 2016 at 6:16 AM, Ingo Molnar <mi...@kernel.org> wrote:
>
> So an ABI distinction and offloading the decision to every single application
> that
> wants to use it and hardcode it into actual application source code via an
> ABI is
> pretty much the _WORST_ way to go about it IMHO...
>
> So how about this: don't add any ABI details, but make futexes auto-attached
> on
> NUMA systems (and obviously PREEMPT_RT systems)?
I agree.
Do *not* make this a visible new ABI.
You will find that people will make exactly the wrong choices - either
not using it (because the futex is deep in a standard library!) when
they want to, or using it when they shouldn't (because the futex is
deep in a standard library, and the library writer knows *his* code is
so important that it should get a special faster futex).
So I absolutely detest this approach. It's the wrong way to go about
things. User space does *not* know whether they want to use this or
not, and they *will* be wrong.
So automatically using a local hashtable (for private mutexes - I
think people need to just accept that a shared mutex is more costly)
according to some heuristic is definitely the way to go. And yes, the
heuristic may be well be - at least to start - "this is a preempt-RT
system" (for people who clearly care about having predictable
latencies) or "this is actually a multi-node NUMA system, and I have
heaps of memory".
Then, add a tunable (for root, not per-futex) to allow people to tweak it.
Because the *last* thing you want is programmerrs saying "I'm so
important that I want the special futex". Because every single
programmer thinks they are special and that _their_ code is special. I
know - because I'm special.
Linus
