Re: [PATCH v4 00/25] RSEQ node id and virtual cpu id extensions

[Florian Weimer <fweimer@redhat.com>]

* 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