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

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2144 bytes --]



On 6/9/26 9:52 PM, Vlastimil Babka (SUSE) wrote:
> 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...

It is challenging to avoid that because, let's say, a CPU releases local
lock, goes to sleep to reclaim memory to allocate a sheaf, re-acquire
the lock, and install it. But sheaf capacity might change or sheaves can
be disabled in the meantime.

Probably wrapping the entire alloc/free path with something like
SRCU-fast might help avoid that... but that sounds quite ambitious (to me).

-- 
Cheers,
Harry / Hyeonggon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]