Re: [PATCH v6] mm/slub: defer freelist construction until after bulk allocation from a new slab

[hu.shengming]

Hao wrote:
> On Mon, Apr 13, 2026 at 11:04:17PM +0800, hu.shengming@xxxxxxxxxx wrote:
> > From: Shengming Hu <hu.shengming@xxxxxxxxxx>
> > 
> > Allocations from a fresh slab can consume all of its objects, and the
> > freelist built during slab allocation is discarded immediately as a result.
> > 
> > Instead of special-casing the whole-slab bulk refill case, defer freelist
> > construction until after objects are emitted from a fresh slab.
> > new_slab() now only allocates the slab and initializes its metadata.
> > refill_objects() then obtains a fresh slab and lets alloc_from_new_slab()
> > emit objects directly, building a freelist only for the objects left
> > unallocated; the same change is applied to alloc_single_from_new_slab().
> > 
> > To keep CONFIG_SLAB_FREELIST_RANDOM=y/n on the same path, introduce a
> > small iterator abstraction for walking free objects in allocation order.
> > The iterator is used both for filling the sheaf and for building the
> > freelist of the remaining objects.
> > 
> > Also mark setup_object() inline. After this optimization, the compiler no
> > longer consistently inlines this helper in the hot path, which can hurt
> > performance. Explicitly marking it inline restores the expected code
> > generation.
> > 
> > This reduces per-object overhead when allocating from a fresh slab.
> > The most direct benefit is in the paths that allocate objects first and
> > only build a freelist for the remainder afterward: bulk allocation from
> > a new slab in refill_objects(), single-object allocation from a new slab
> > in ___slab_alloc(), and the corresponding early-boot paths that now use
> > the same deferred-freelist scheme. Since refill_objects() is also used to
> > refill sheaves, the optimization is not limited to the small set of
> > kmem_cache_alloc_bulk()/kmem_cache_free_bulk() users; regular allocation
> > workloads may benefit as well when they refill from a fresh slab.
> > 
> > In slub_bulk_bench, the time per object drops by about 32% to 70% with
> > CONFIG_SLAB_FREELIST_RANDOM=n, and by about 50% to 67% with
> > CONFIG_SLAB_FREELIST_RANDOM=y. This benchmark is intended to isolate the
> > cost removed by this change: each iteration allocates exactly
> > slab->objects from a fresh slab. That makes it a near best-case scenario
> > for deferred freelist construction, because the old path still built a
> > full freelist even when no objects remained, while the new path avoids
> > that work. Realistic workloads may see smaller end-to-end gains depending
> > on how often allocations reach this fresh-slab refill path.> 

> Thanks for both Shengming and Harry's hard work!> 

> This patch looks good to me, and the overall approach makes sense. I did not
> see any other issues, so:> 

> Reviewed-by: Hao Li <hao.li@xxxxxxxxx>> 

> I also ran a few tests on my machine. From what I saw, the mmap and ublk
> cases did not show a very noticeable difference, but I also did not observe any
> regression, which is great. My guess is that the fully consumed case as an
> ideal scenario may still be relatively uncommon in practice.> 

> Tested-by: Hao Li <hao.li@xxxxxxxxx>> 

Hi Hao,

Thank you for your review and for running the tests.
This patch primarily optimizes the allocation path when a new slab is required.
The mmap and ublk cases may not exercise this path very frequently, which could
explain why the performance difference is not very noticeable there.

Have a good day! :-)

--
With Best Regards,
Shengming

> -- 
> Thanks,
> Hao