Messages in this thread | | | From | Florian Weimer <> | Subject | Re: [PATCH v4 00/25] RSEQ node id and virtual cpu id extensions | Date | Mon, 10 Oct 2022 15:04:29 +0200 |
| |
* 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
| |