On Tue, Feb 16, 2021 at 11:20:44AM +0100, Sebastian Andrzej Siewior wrote: > On 2021-02-16 10:56:14 [+0100], Peter Zijlstra wrote: > > So while I'm in favour of adding a new interface, I'm not sure I see > > benefit of reimplementing the basics, sure it seems simpler now, but > > that's because you've not implemented all the 'fun' stuff. > > The last attempt tried to hide the updated interface within libc which > did not fly. The global hash state is one of the problems because it > leads to hash collisions of two unrelated locks. > It will get simpler if we go into the kernel for each lock/unlock > operation but this might not very good in terms of performance for locks > which are mostly uncontended. I'm not sure how much we can cheat in > terms of VDSO.
I'm sorry, but I'm failing to understand any of that. How is adding a second global hash going to solve anything? Also, the LOCK/UNLOCK primitives as we have them today very much rely on a userspace fast path, and I don't see that changing. Only on contention do we call into the kernel. The advantage of the new interface is having that NUMA word along with the Futex word, in which we can store the node_id for the hash we stuffed the futex in, which is awesome, but that too doesn't need a re-implementation of all the basics. And getting rid of the super multiplexer is also nice. But re-implementing all the basic stuff again, not so nice.
