Re: [PATCH RFC 0/8] mm/slab: enable runtime sheaves tuning

[Harry Yoo <harry@kernel.org>]

On 5/18/26 8:52 PM, Pedro Falcato wrote:
> On Sat, May 16, 2026 at 01:24:24AM +0900, Harry Yoo (Oracle) wrote:
>> Background
>> ==========
>>
>> Sheaves were introduced in v6.18, and starting from v7.0, they are
>> enabled for all slab caches (except for kmem_cache{,_node}). In the
>> pre-sheaves era, there was a cpu_partial parameter to tune the number
>> of objects cached per CPU. However, sheaves don't have an equivalent
>> and the sheaf capacity is determined in the kernel code.
> 
> What semantic do you need from this?

The intent is to allow adjusting sheaf capacity to mitigate per-node 
barn / slab list contention on the slowpath (for servers with many 
CPUs), similar to the 'cpu_partial' tunable in SLUB and the 'limit' 
tunable in SLAB.

However, the semantics are slightly different from 'cpu_partial' and 
'limit', as changing sheaf_capacity also affects the number of objects 
cached in the barn.
>> Challenges
>> ==========
>>
>> 1. Allocations and frees can happen concurrently at any point between
>>     these steps, and we cannot introduce heavyweight synchronization
>>     mechanisms on the fastpath.
>>
>> 2. Currently, cache_has_sheaves() checks whether a cache has sheaves.
>>     This works now because sheaves cannot be enabled or disabled once
>>     the cache is created.
>>
>>     The question "Does this cache has sheaves?" should be split into
>>     "Does this cache support sheaves?" and "Does this CPU actually has
>>      sheaves enabled right now?".
>>
>> 3. Once the sheaf capacity update is complete, no sheaf with stale
>>     capacity must remain.
> 
> Why? I don't see a huge problem with having multiple sheaves with different
> capacities, as long as you adequately, opportunistically kill the sheaves
> if they don't have the desired size (say, once a sheaf is fully empty).

Haha, you got me.

Right, enforcing a single capacity at any given point introduced so much 
complexity that I started wondering myself about whether this is really 
essential.

My main concern was that the performance characteristics would become 
too unpredictable, but actually, users can avoid that by disabling 
sheaves, shrinking it, and re-enabling it. So that's not an enough 
justification.

When I first started, I was quite cautious and obsessed with the 
invariant because many parts of the current implementation assume "a 
kmem_cache has only a single capacity, and it doesn't change", but 
that's also addressed by this patchset. So that's not a big issue either.

I agree that it is worth trying to allow sheaves of different capacities 
and hopefully that would be less intrusive. Let's see.

Thank you, Pedro.

-- 
Cheers,
Harry / Hyeonggon