Re: [RFC PATCH 1/2] rseq: extend struct rseq with numa node id

----- On Jan 31, 2022, at 4:19 PM, Florian Weimer fw@deneb.enyo.de wrote:

* Mathieu Desnoyers:

quoted

Adding the NUMA node id to struct rseq is a straightforward thing to do,
and a good way to figure out if anything in the user-space ecosystem
prevents extending struct rseq.

This NUMA node id field allows memory allocators such as tcmalloc to
take advantage of fast access to the current NUMA node id to perform
NUMA-aware memory allocation.

It is also useful for implementing NUMA-aware user-space mutexes.

It can be used to implement getcpu purely in userspace, too.  I had
plan to hack this together with a node ID cache in TLS, which should
offer pretty much the same functionality (except for weird CPU
topology changes which alter the node ID of a previously used CPU).

I suspect that any approach based on a user-space cache will break with
respect to CRIU. That is one big advantage of using the rseq thread area
for this.

However, I do not understand the need for two fields here.  Why isn't
one enough?

As stated in my self-reply, I don't think those two fields are needed
after all.

One field would also avoid the need to mess with rseq_cpu_id_state,
maintaining API compatibility.

True. However considering that we plan to remove the buggy "rseq_cs.ptr"
fields from the API, that rseq.h UAPI compatibility does not seem to be
very much relevant.

But still, it's better if we can avoid breaking API, agreed. And the
"node_id_start" does not appear to be needed after all.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com