Linux 7.4’s slab allocator refills its sheaves from the barn and gains 24% in memory allocation
An 81-line patch by Hao Li, queued into slab/for-next ahead of the Linux 7.4 merge window, lets the slab allocator refill its sheaves from the barn instead of partial slabs, clearing a saturation that penalized kfree_rcu(). The measured result: +24% on the will-it-scale mmap1 test and massive gains on the barn microbenchmarks.
September 26, 2026. Michael Larabel documents on Phoronix a memory-management patch queued into the slab/for-next branch, ahead of the Linux 7.4 merge window expected in late October. September 26, 2026. Its author, Hao Li, describes an 81-line change to how the slab allocator refills its sheaves. A year earlier, sheaves entered the kernel as a per-CPU caching layer. Why it matters: a quiet saturation of the allocator’s “barn” was forcing expensive work on every kfree_rcu(), and this patch clears it — with a measured 24% gain on a realistic benchmark. For anyone running RCU-heavy workloads at scale, that is a free win with no interface changes and no added risk to the generic path.
Sheaves, the allocator’s per-CPU caching layer
Sheaves are the per-CPU, array-based caching layer of the kernel’s memory allocator. They store freed objects for fast reallocation, avoiding a trip back through the global SLUB structures. Since their introduction last year, they have absorbed much of the allocator’s optimization effort, because they directly shape cache locality and lock contention on high-core-count machines.
Understanding the patch requires distinguishing two allocation paths. The generic path exchanges an empty sheaf for a full one taken from the “barn” — the central reservoir of full sheaves. The prefill path, by contrast, refills a sheaf that is not necessarily empty. That is where the problem lived.
The problem: a barn that saturates and never drains
Until now, when the prefill API refilled a non-full sheaf, it took objects only from partial slabs, never from the full sheaves in the barn. The mechanical consequence: once the barn’s “full” list saturates, it stays saturated. Nothing ever drains it.
For objects freed via kfree_rcu(), the effect is direct and costly. Every RCU sheaf then had to be flushed to slabs, because the barn’s full list had no room. kfree_rcu() is everywhere — it frees memory deferred until the RCU grace period ends, on hot paths like inode deletion or the teardown of network connections. Forcing a flush to slabs every time means falling back into the exact cost the sheaves were meant to remove.
The patch: refill from the barn, with a partial sheaf
Hao Li’s change reverses the priority. The prefill path starts by refilling from the barn, then introduces a partial sheaf in the barn to hold the leftover objects. In practice: the sheaf is refilled by copying objects from the partial sheaf, then, if still not full, from a full sheaf taken from the barn. A sheaf whose objects were copied stays in the barn as the partial sheaf if it still holds objects, or moves to the empty list if empty. The sheaf being refilled is never replaced.
The gain comes from two directions. First, every full sheaf taken out makes room on the barn’s full list for a future RCU sheaf — the saturation drains instead of freezing. Second, refilling from the barn is cheaper than refilling from partial slabs under the list_lock. As Hao Li puts it: “The gain comes from two sides: every full sheaf taken out makes room on the barn’s full list for a future RCU sheaf, and refilling from the barn is cheaper than refilling from partial slabs under list_lock.”
The numbers: 24% on a realistic benchmark
The published measurements show an overall 24% improvement on the will-it-scale mmap1 test — a benchmark that stresses memory allocation realistically, not a synthetic microbenchmark. On the targeted barn microbenchmarks, the gains are dramatic: barn_get and barn_put report eight-digit percentage figures whose raw reading is misleading because the baseline is near zero, while the remaining metrics improve by double-digit percentages.
The contrast between the realistic +24% and the vertiginous microbenchmark percentages is itself a lesson: it is the will-it-scale number that matters for production, while the others only confirm that the critical path is the one you think it is. And all of it from 81 lines of new code — a rare density of gain, even in the memory subsystem.
Why it matters in production
Kernel memory management is a fixed cost of almost every datacenter workload. Allocator improvements do not show up in any single application benchmark; they compound across every kmalloc, every kfree_rcu, every file open. Reducing contention on list_lock benefits high-core-count machines first — precisely where barn saturation appears earliest.
The patch is destined for Linux 7.4, whose merge window opens in late October. It will change nothing for current distributions — Ubuntu 26.10 ships Linux 7.3 — but it maps the trajectory: the allocator keeps specializing around sheaves, and optimizations in this layer are becoming a first-class performance lever, alongside the scheduler and the network stack. To check the active allocator and inspect slab state on a machine, two commands suffice:
grep CONFIG_SLAB /boot/config-$(uname -r)
cat /proc/slabinfo | headThe workloads that benefit most are those that free memory through RCU at scale: filesystem teardown, connection shutdown in high-throughput proxies, and any service that creates and destroys objects in tight loops across many cores. On such machines the barn’s full list saturates quickly, and every forced flush to slabs adds list_lock contention that shows up as tail latency rather than average throughput. The 24% will-it-scale mmap1 gain is a fair proxy for exactly this class of workload — and because the change only touches the prefill path, it carries no risk to the generic allocation path that every other workload uses. For kernel maintainers, that is the whole point: a surgical fix on a hot but narrow path, cheap to review and easy to revert, that does not disturb the code every other allocator user depends on.
An allocator that keeps giving
This architecture did not appear overnight. The SLUB allocator, the kernel’s default since 2007, long relied on simple per-CPU caches; the addition of sheaves last year — work driven in large part by Vlastimil Babka — introduced a fine-grained reuse layer built to exploit cache locality more aggressively. Hao Li’s patch refines exactly that layer: it changes no interface, but fixes a refill path that had become suboptimal as sheaves spread through the kernel. That history matters for what follows: the allocator is no longer a frozen subsystem, but one where small, surgical changes still deliver measurable wins.
Verdict
If you track kernel development releases or are preparing a move to Linux 7.4, remember this patch as a near-zero-cost memory win — 81 lines, no interface changes, a measured benefit on a realistic path. If you run heavily multithreaded, allocation-latency-sensitive workloads, watch for this change to land in stable kernels and test it against your internal microbenchmarks: it is the kind of optimization that translates into real CPU savings without changing a single line of application code. If kernel development is not your world, the takeaway lies elsewhere: memory performance is now decided in the sheaf layer, and the allocator’s “free” gains are far from exhausted. A saturation that was silently freezing has just found its relief valve — the kind of patch that never makes headlines, but makes everything else faster.