Re: [RFC PATCH 0/2] mm/slub: reduce list_lock contention with slab parking

[Hao Li <hao.li@linux.dev>]

On Tue, Sep 15, 2026 at 09:10:22AM +0200, Vlastimil Babka (SUSE) wrote:
> On 9/11/26 13:24, Hao Li wrote:
> > On Mon, Sep 07, 2026 at 03:44:08PM +0200, Vlastimil Babka (SUSE) wrote:
> >> On 8/24/26 14:19, Hao Li wrote:
> >> > 
> >> > Detailed data
> >> > -------------
> >> > 
> >> > metric                              before             after             delta      change
> >> > ==========================================================================================
> >> > alloc_fastpath                     155,417           168,534            13,117      +8.44%
> >> > alloc_slab                      55,679,646        26,702,510       -28,977,136     -52.04%
> >> 
> >> It's interesting that this is reduced so much. Is it because parked slabs
> >> cause more slabs to stay around for reuse, despite they are unparked
> >> immediately when trying to allocate/refill? That seems odd?
> > 
> > Yeah, it does look counter-intuitive at first glance. My understanding is that
> > the parking mechanism helps by bypassing the partial list spinlock, allowing
> > partial slabs to be parked onto the llist locklessly at any point. Because of
> > this, the refill path gets to see and reuse more partial slabs instead of
> > having to allocate fresh ones so frequently.
> 
> Hmm that's an interesting effect, surprisingly large if true. Because the
> slabs we'd be parking are transitioning from full, there would be most often
> just a single free object to reuse?

That makes sense. That said, it might be more than a single object, since
build_detached_freelist() tries to free objects from the same slab together.

Even though we "park" the parking series for now, I was still curious to
understand the underlying behavior. So I add a counter in
get_partial_node_bulk() to see how many partial slabs it can see.
(counting freed objects directly is tough, so the partial slab count gives us a
rough picture)

Interestingly, each get_partial_node_bulk() on the patched kernel saw about
3-4x more partial slabs on average compared to baseline. This suggest that the
parking mechanism can supply more allocatable objects even under lock
contention, since it can avoid waiting for list lock.

For example, in the baseline kernel, if the lock is held by an allocator, a
freer has to wait on it. Once it's released, the lock might just get grabbed by
yet another allocator, leaving the freer stuck waiting. As a result, the
partial list ends up starved of free objects.


-- 
Thanks,
Hao