CPU affinity behavior of liburcu call-rcu per-cpu worker threads

[Mathieu Desnoyers]

On 2026-07-10 00:07, Paul E. McKenney wrote:
> On Thu, Jul 09, 2026 at 10:56:51PM -0400, Mathieu Desnoyers wrote:
>> On 2026-07-09 22:53, Paul E. McKenney wrote:
>> [...]
>>>
>>>> And unfortunately, for me, tcmalloc is really not a viable option,
>>>> because it needs to own the RSEQ area registration, and because glibc
>>>> cannot use it at the same time as tcmalloc, my benchmarks suffer because
>>>> glibc has a slower sched_getcpu() implementation.
>>>>
>>>> So jemalloc it is. tcmalloc is not usable for me because they don't
>>>> compose with the rest of the world. I warned the tcmalloc developers
>>>> many times, but they did not listen. :-(
>>>
>>> So an alternative rseq for the rest of us?
>>
>> I'm not quite sure I understand. Since there is only one rseq
>> registration per thread, this means that tcmalloc require their
>> users to use a GLIBC tunable to disable rseq registration at the
>> libc level, leaving rseq solely to tcmalloc.
> 
> Could an independent thing very closely resembling rseq be brought into
> being alongside the current rseq, so that tcmalloc gets the existing
> one and everyone else plays nice and shares the new one?

That would unfortunately roll the clock backward about 5 years in terms
of glibc integration, which supports rseq out of the box since version
2.35 (Feb 2022).

Moreover, if we add a second rseq area, this means the kernel now need
to have code to support both areas in key performance-critical code
areas (scheduler, interrupt entry/exit).

So no, as far as I am concerned, this is really not an option.

The "simpler" option would be to implement the rseq extension tcmalloc
need, so they can finally stop doing their odd games and become
compatible with the rest of the world. But the last time I offered to
help them on this front I've been told that they would not even have
time to try my patches.

Oh well.

Thanks,

Mathieu

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