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

[Ryan Roberts <ryan.roberts@arm.com>]

On 27/03/2026 07:54, Vlastimil Babka (SUSE) wrote:
> 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.

ACK

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

Ahh sorry I missed your first email. We only added that benchmark from 6.19 so
don't have results for earlier kernels, but I'll ask Aishu to run it for 6.17
and 6.18 to see if the results correlate with your expectation.

But from a high level perspective, a 7% regression on fork is not ideal even if
there was a 7% improvement in 6.18.

Thanks,
Ryan

> 
> Thanks!
> Vlastimil
> 
>> Thanks,
>> Ryan
>>
>>
>>>
>>>>
>>>> --
>>>> Uladzislau Rezki
>>>
>>
>