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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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