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

[Paul E. McKenney]

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?

							Thanx, Paul