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

[Vlastimil Babka (SUSE)]

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?

>> 
>> > alloc_slowpath                           0                 0                 0      +0.00%
>> > barn_get                             2,715             2,771                56      +2.06%
>> > barn_get_fail                            2                 0                -2    -100.00%
>> > barn_put                             2,715             2,770                55      +2.03%
>> > barn_put_fail                1,370,488,457     1,668,257,974       297,769,517     +21.73%
>> > cmpxchg_double_fail              3,827,935           549,427        -3,278,508     -85.65%
>> > free_add_partial             1,684,340,964     2,161,921,625       477,580,661     +28.35%
>> > free_fastpath                       31,766            32,979             1,213      +3.82%
>> > free_rcu_sheaf              43,855,689,417    53,384,314,553     9,528,625,136     +21.73%
>> 
>> This metric (and others with similar numbers) should not be affected by the
>> change. Does it mean the benchmark has a fixed time to run, but manages to
>> do more work in that time thanks to the increased throughput?
> 
> Exactly! In fact, the increase in free_rcu_sheaf matches the throughput gain
> almost 1:1. A ~21% increase in throughput naturally translates to ~21% more object
> allocations and frees.

Ack!