* Mathieu Desnoyers: > Extend the rseq ABI to expose a NUMA node ID and a vm_vcpu_id field. > > The NUMA node ID field allows implementing a faster getcpu(2) in libc. > > The virtual cpu id allows ideal scaling (down or up) of user-space > per-cpu data structures. The virtual cpu ids allocated within a memory > space are tracked by the scheduler, which takes into account the number > of concurrently running threads, thus implicitly considering the number > of threads, the cpu affinity, the cpusets applying to those threads, and > the number of logical cores on the system. Do you have some code that shows how the userspace application handshake is supposed to work with the existing three __rseq_* symbols? Maybe I'm missing something. >From an application perspective, it would be best to add 8 more shared bytes in use, to push the new feature size over 32. This would be clearly visible in __rseq_size, helping applications a lot. Alternatively, we could sacrifice a bit to indicate that the this round of extensions is present. But we'll need another bit to indicate that the last remaining 4 bytes are in use, for consistency. Or come up with something to put their today. The TID seems like an obvious choice. If we want to the 8 more bytes route, TID and PID should be uncontroversal? The PID cache is clearly something that userspace likes, not just as a defeat device for the old BYTE benchmark. Thanks, Florian