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

[Paul E. McKenney]

On Fri, Jul 10, 2026 at 12:17:39AM -0400, Mathieu Desnoyers wrote:
> 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.

I bet that there is a way, but thus far I at least add a load and a branch
to those fastpaths.  Maybe convince someone to submit the needed patches
to tcmalloc() and then browbeat the tcmalloc() folks into accepting them?
You would need someone young, energetic, and obnoxious, which lets me
off on two of the three.  ;-)

							Thanx, Paul