Re: [PATCH RFC 12/19] slab: remove the do_slab_free() fastpath

[Vlastimil Babka <vbabka@suse.cz>]

On 10/25/25 00:32, Alexei Starovoitov wrote:
> On Thu, Oct 23, 2025 at 6:53 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>> @@ -6444,8 +6316,13 @@ void kfree_nolock(const void *object)
>>          * since kasan quarantine takes locks and not supported from NMI.
>>          */
>>         kasan_slab_free(s, x, false, false, /* skip quarantine */true);
>> +       /*
>> +        * __slab_free() can locklessly cmpxchg16 into a slab, but then it might
>> +        * need to take spin_lock for further processing.
>> +        * Avoid the complexity and simply add to a deferred list.
>> +        */
>>         if (!free_to_pcs(s, x, false))
>> -               do_slab_free(s, slab, x, x, 0, _RET_IP_);
>> +               defer_free(s, x);
> 
> That should be rare, right?
> free_to_pcs() should have good chances to succeed,
> and pcs->spare should be there for kmalloc sheaves?

Yes.

> So trylock failure due to contention in barn_get_empty_sheaf()
> and in barn_replace_full_sheaf() should be rare.

Yeah, while of course stress tests like will-it-scale can expose nasty
corner cases.

> But needs to be benchmarked, of course.
> The current fast path cmpxchg16 in !RT is very reliable
> in my tests. Hopefully this doesn't regress.

You mean the one that doesn't go the "if (unlikely(slab != c->slab))" way?
Well that unlikely() there might be quite misleading. It will be true when
free follows shortly after alloc. If not, c->slab can be exhausted and
replaced with a new one. Or the process is migrated to another cpu before
freeing. The probability of slab == c->slab staying true drops quickly.

So if your tests were doing frees shortly after alloc, you would be indeed
hitting it reliably, but is it representative?
However sheaves should work reliably as well too with such a pattern, so if
some real code really does that significantly, it will not regress.