The slab memory allocator feature updates have been merged for the [1]Linux 7.0 kernel. Most notable this cycle is expanded use of the recently-introduced Sheaves functionality.

[2]Merged back in Linux 6.19 was Sheaves as what began as [3]an opt-in, per-CPU array-based caching layer with [4]the potential of further helping Linux performance . Now with Linux 7.0 the Sheaves functionality is taking on a much bigger role.

Beginning with Linux 7.0, [5]Sheaves is replacing more of the Linux kernel's caching code with hopes of this new implementation further enhancing performance. So far I haven't seen any benchmarks to quantify the impact of this change but the code commits mention "hope" for improving performance.

The [6]slab pull request that is now merged for Linux 7.0 explains of the expanded Sheaves use:

"The percpu sheaves caching layer was introduced as opt-in in 6.18 and now we enable it for all caches and remove the previous cpu (partial) slab caching mechanism. Besides the lower locking overhead and much more likely fastpath when freeing, this removes the rather complicated code related to the cpu slab lockless fastpaths (using this_cpu_try_cmpxchg128/64) and all its complications for PREEMPT_RT or kmalloc_nolock().

The lockless slab freelist+counters update operation using try_cmpxchg128/64 remains and is crucial for freeing remote NUMA objects, and to allow flushing objects from sheaves to slabs mostly without the node list_lock."

The merged slab code for Linux 7.0 also elimates slabobj_ext metadata overhead where possible as an efficiency improvement by reusing leftover space in a slab or per-object padding.



[1] https://www.phoronix.com/search/Linux+7.0

[2] https://www.phoronix.com/news/Linux-6.18-Slab-Sheaves

[3] https://www.phoronix.com/news/Linux-6.18-Likely-Sheaves

[4] https://www.phoronix.com/news/Linux-Sheaves-AMD-Performance

[5] https://www.phoronix.com/news/Linux-7.0-Replace-Slabs-Sheaves

[6] https://lore.kernel.org/lkml/34ac32fe-e082-485b-bead-4e6b9ae6a153@suse.cz/