Re: [REGRESSION] slab: replace cpu (partial) slabs with sheaves

Vlastimil Babka (SUSE)
2026-03-27T07:54:18Z

On 3/26/26 19:50, Ryan Roberts wrote:
> On 26/03/2026 18:24, Vlastimil Babka (SUSE) wrote:
>> On 3/26/26 19:16, Uladzislau Rezki wrote:
>>> On Thu, Mar 26, 2026 at 03:42:02PM +0100, Vlastimil Babka (SUSE) wrote:
>>>> On 3/26/26 13:43, Aishwarya Rambhadran wrote:
>>>>> Hi Vlastimil, Harry,
>>>>
>>>
>>> static bool kfree_rcu_sheaf(void *obj)
>>> {
>>> struct kmem_cache *s;
>>> struct slab *slab;
>>>
>>> if (is_vmalloc_addr(obj))
>>> return false;
>>>
>>> slab = virt_to_slab(obj);
>>> if (unlikely(!slab))
>>> return false;
>>>
>>> s = slab->slab_cache;
>>> if (likely(!IS_ENABLED(CONFIG_NUMA) || slab_nid(slab) == numa_mem_id()))
>>> return __kfree_rcu_sheaf(s, obj);
>>>
>>> return false;
>>> }
>>>
>>> it does not go via sheaf since it is a vmalloc address.
>
> Isn't vmalloc doing slab allocations for vmap_area, vm_struct, etc, which will
> occasionally go via sheaves though? I had assumed that was the reason of the
> observed regression.

You're right. And in the table Harry fixed up (thanks!) I can see the
regressions are also in tests that don't do kvfree_rcu() but a plain vfree()
so that rules out the overhead of kfree_rcu_sheaf() returning false.

It might be due to sheaf_capacity not matching the capacity of cpu (partial)
slabs. We are working to improve that.

>>
>> Right so there should be just the overhead of the extra is_vmalloc_addr()
>> test. Possibly also the call of kfree_rcu_sheaf() if it's not inlined.
>> I'd say it's something we can just accept? It seems this is a unit test
>> being used as a microbenchmark, so it can be very sensitive even to such
>> details, but it should be negligible in practice.
>
> The perf/syscall cases might be a bit more concerning though? (those tests are
> from "perf bench syscall fork|execve"). Yes they are microbenchmarks, but a 7%
> increased cost for fork seems like something we'd want to avoid if we can.

Sure, I tried to explain those in my first reply. Harry then linked to how
that explanation can be verified. Hopefully it's really the same reason.

Thanks!
Vlastimil

> Thanks,
> Ryan
>
>
>>
>>>
>>> --
>>> Uladzislau Rezki
>>
>