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

[Vlastimil Babka (SUSE)]

On 5/20/26 06:35, Harry Yoo wrote:
> 
>>> ==========
>>>
>>> 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.

My concern would have been that we would need to track capacity per sheaf if
we allowed sheaves with different capacities to coexist.
But patch 3 here already does that, so it seems it's necessary anyway...

> 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.
>