On Tue, Mar 05, 2019 at 05:32:10PM -0500, Mathieu Desnoyers wrote: > ----- On Mar 5, 2019, at 4:58 PM, Peter Zijlstra peterz@xxxxxxxxxxxxx wrote: > > > On Tue, Mar 05, 2019 at 03:18:35PM -0500, Mathieu Desnoyers wrote: > >> * NUMA node ID in TLS > >> > >> Having the NUMA node ID available in a TLS variable would allow glibc to > >> perform interesting NUMA performance improvements within its locking > >> implementation, so I have a patch adding NUMA node ID support to rseq > >> as a new rseq system call flag. > > > > Details? There's just not much room in the futex word, and futexes > > themselves are not numa aware. > > It was discussed in this libc-alpha mailing list thread: > > https://public-inbox.org/libc-alpha/CAMe9rOo7i_-keOooa0D+P_wzatVCdKkTRiFiJ-cxpnvi+eApuQ@xxxxxxxxxxxxxx/ > > (adding the relevant people in CC) > > I'd like to hear in more details on how they intend to design > NUMA-aware spinlocks within glibc. All I know is that quick > access to the node ID would help for this. Userspace spinlocks are a trainwreck anyway. The only case where they can possibly work is when there's only a single thread on every cpu. Pretty much any other scenario is fail; see why we have paravirt spinlocks.
