3 ms·
I think most allocators don't care which core you call free on. It's already the case that you can malloc from any core and free on another. Special purpose al
by uluyol 5y ago
I think most allocators don't care which core you call free on. It's already the case that you can malloc from any core and free on another.
Special purpose allocators maybe. Agree that this mechanism overall is rather niche, but that niche (malloc) is a rather important one.
- PaulDavisThe1st 5y agoIn the GP comment from @teraflop: > As the article says at the beginning, this is intended for per-CPU data structures, not shared ones.
- CaliforniaKarl 5y agoIndeed. And even though glibc has only recently introduced support for rseq, the rseq system call has been around for a while. Search around, I found tcmalloc (https://google.github.io/tcmalloc/ https://google.github.io/tcmalloc/) is an example of software that is using rseq today, without glibc's support. And as far as I can tell, tcmalloc is using rseq both with a 'per-CPU' structure (actually portions of a larger block of memory), and without a requirement to pin processes or threads to a particular CPU. Their design document (https://google.github.io/tcmalloc/rseq.html https://google.github.io/tcmalloc/rseq.html) might be of interest to you.
- uluyol 5y agoThe original use case (I believe) was tcmalloc. Tcmalloc maintained per-thread caches of free memory, but that's wasteful since it increases fragmentation but has no parallelism advantage compared to per-CPU buffers. OTOH, you can't just use per-CPU data since you can get preempted, hence rseq. malloc from the per-CPU cache without locking, and free to any other cache without locking.