Re: [PATCH v4 06/22] slab: add sheaves to most caches

[Vlastimil Babka <vbabka@suse.cz>]

On 1/30/26 08:15, Zhao Liu wrote:
> Hi Vlastimil,
> 
>> > vm_area_cachep's capacity seems to be adjusted to 60 and
>> > maple_node_cache keeps 32 as the args setting.
>> 
>> Good to know. It is a bit larger.
>> Hm I could have probably applied the args capacity before doing the roundup
>> to make sheaf fill whole kmalloc size. Would add a few object for maple node
>> I guess.
> 
> Re-considerring this formula:
> 
> the nr_objects in set_cpu_partial() in fact represents the half-full
> case since it was used to calculate nr_slabs in slub_set_cpu_partial().
> 
> Therefore, the maximum capacity of this partial approach should be
> nr_objects * 2 (and should actually be even larger, since it doesn't
> account for the object on CPU's freelist).
> 
> But here, for sheaf, the implicit assumption is that it is completely
> full, so that for the maximum capacity of objects per CPU, the sheaf
> approach is "half" that of the partial approach.
> 
> Is this expected? I'm considering whether we should remove the
> “divide by two” and instead calculate the sheaf capacity based on
> half-full assumption (e.h., full main & empty spare).

Yeah the non-doubling was intentional. Sheaves can be always fully filled up
by freeing and fully emptied by allocating. Cpu partial slabs don't make
freeing as cheap (except never needing the list_lock perhaps) because it's
the locked double cmpxchg patch. For allocation, we might be obtaining them
from the partial list either on allocation where they might have any number
of free objects between 1 and slab size, or we put them to partial list on a
first free to a full slab - and then there will be just single free object,
but we hope there will be more frees before we turn that slab into cpu slab.

So the half-full case is an estimate that might be even actually less as the
freeing side is biased to almost-full slabs.

With sheaves no such estimate is necessary. Not accounting for the cpu slab
size was maybe a mistake. In any case we can tune the sizes later, but this
should not be based on synthetic benchmark only.

Thanks,
Vlastimil

> Thanks,
> Zhao
> 
>