On Tue, Mar 05, 2019 at 05:32:10PM -0500, Mathieu Desnoyers wrote:
----- On Mar 5, 2019, at 4:58 PM, Peter Zijlstra peterz@infradead.org wrote:
quoted
On Tue, Mar 05, 2019 at 03:18:35PM -0500, Mathieu Desnoyers wrote:
quoted
* 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@mail.gmail.com/
(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.