Re: [RFC PATCH] slub: spill refill leftover objects into percpu sheaves

["Harry Yoo (Oracle)" <harry@kernel.org>]

On Fri, Apr 10, 2026 at 07:16:57PM +0800, Hao Li wrote:
> When performing objects refill, we tend to optimistically assume that
> there will be more allocation requests coming next; this is the
> fundamental assumption behind this optimization.

I think the reason why currently we have two sheaves per CPU instead of
one bigger sheaf is to avoid unfairly pessimizing when the alloc/free
pattern frequently changes.

By refilling more objects, frees are more likely to hit the slowpath.
How can it be argued that this optimization is beneficial to have
in general, not just for caches with specific alloc/free patterns?

> When __refill_objects_node() isolates a partial slab and satisfies a
> bulk allocation from its freelist, the slab can still have a small tail
> of free objects left over. Today those objects are freed back to the
> slab immediately.
> 
> If the leftover tail is local and small enough to fit, keep it in the
> current CPU's sheaves instead. This avoids pushing those objects back
> through the __slab_free slowpath.

So there are two different paths:

1. When refilling prefilled sheaves, spill objects into ->main and
   ->spare. 
2. When refilling ->main sheaf, spill objects into ->spare.
 
> Add a helper to obtain both the freelist and its free-object count, and
> then spill the remaining objects into a percpu sheaf when:
> - the tail fits in a sheaf
> - the slab is local to the current CPU
> - the slab is not pfmemalloc
> - the target sheaf has enough free space
> 
> Otherwise keep the existing fallback and free the tail back to the slab.
> 
> Also add a SHEAF_SPILL stat so the new path can be observed in SLUB
> stats.
> 
> On the mmap2 case in the will-it-scale benchmark suite,

> this patch can improve performance by about 2~5%.

Where do you think the improvement comes from? (hopefully w/ some data)

e.g.:
  1. the benefit is from largely or partly from
     reduced contention on n->list_lock.

  2. this change reduces # of alloc slowpath at the cost of increased
     of free slowpath hits, but that's better because the slowpath frees
     are mostly lockless.

  3. the alloc/free pattern of the workload is benefiting from
     spilling objects to the CPU's sheaves.

or something else?

> Signed-off-by: Hao Li <hao.li@linux.dev>
> ---
> 
> This patch is an exploratory attempt to address the leftover objects and
> partial slab issues in the refill path, and it is marked as RFC to warmly
> welcome any feedback, suggestions, and discussion!

Yeah, let's discuss!

By the way, have you also been considering having min-max capacity
for sheaves? (that I think Vlastimil suggested somewhere)

-- 
Cheers,
Harry / Hyeonggon