(Not an expert but ...) unless you pin threads to cores, which is not the default and somewhat awkward in Linux for user applications, having a per-thread cache doesn't really make sense as your thread could be moved to another core and then your cache will no longer be local to the physical cache.
i think we agree that per cpu caching seems superior. i’m looking for the other side of this. most allocators seem to have stuck with per thread.
If you use a thread-local data structure, your allocator can pretend that it is running on a single-core, single-task system.
If you use a CPU-local data structure, you must handle the case where, mid-way through a call to your allocator, the CPU runs a second thread that makes another call to your allocator (and that, too, can get interrupted by another thread that allocates memory, etc.)
That makes thread-local easier to implement and likely faster (it doesn’t require any memory barriers in the fast path)
Also, good schedulers try to avoid moving threads between CPUs. The better they manage to do that, the lower the cost of having per thread data structures (there likely still is a price, as there most of the time are more threads than CPUs on a system)
https://google.github.io/tcmalloc/rseq.html
i don’t believe rseq based cpu local caches require memory barriers on the fast path.