Re: [PATCH v2 05/16] mm/slab: introduce alloc_flags and SLAB_ALLOC_TRYLOCK

[Vlastimil Babka (SUSE)]

On 6/15/26 04:16, Alexei Starovoitov wrote:
> On Sun, Jun 14, 2026 at 7:01 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>>
>> On Thu, Jun 11, 2026 at 8:50 PM Hao Li <hao.li@xxxxxxxxx> wrote:
>> >
>> > On Wed, Jun 10, 2026 at 05:40:07PM +0200, Vlastimil Babka (SUSE) wrote:
>> > > Similarly to the page allocators, introduce slab-allocator specific
>> > > alloc flags that internally control allocation behavior in addition to
>> > > gfp_flags, without occupying the limited gfp flags space.
>> > >
>> > > Introduce the first flag SLAB_ALLOC_TRYLOCK that behaves similarly to
>> > > page allocator's ALLOC_TRYLOCK and will be used to reimplement
>> > > kmalloc_nolock()'s "!allow_spin" behavior. That currently relies on
>> > > gfpflags_allow_spinning() and thus the lack of both __GFP_RECLAIM flags,
>> > > importantly __GFP_KSWAPD_RECLAIM. This can give false-positive results
>> > > e.g. in early boot with a restricted gfp_allowed_mask.
>> > >
>> > > Also introduce alloc_flags_allow_spinning() to replace the usage of
>> > > gfpflags_allow_spinning().
>> > >
>> > > Start using alloc_flags and the new check first in alloc_from_pcs() and
>> > > __pcs_replace_empty_main(). This means some slab allocations that were
>> > > falsely treated as kmalloc_nolock() due to their gfp flags will now have
>> > > higher chances of succeed, and this will further increase with followup
>>
>> nit: I think it should be either "higher chances of succeess" or
>> "higher chances to succeed".

success it is

>>
>> > > changes.
>> > >
>> > > Remove a WARN_ON_ONCE() from refill_objects() as it's now legitimate to
>> > > reach it from a slab allocation that's not _nolock() and yet lacks
>> > > __GFP_KSWAPD_RECLAIM for other reasons.
>> > >
>> > > Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
>> > > ---
>> >
>> > Reviewed-by: Hao Li <hao.li@xxxxxxxxx>
>>
>> I would call SLAB_ALLOC_TRYLOCK something like SLAB_ALLOC_NOSPIN or
>> SLAB_ALLOC_NOLOCK but naming is hard and I don't claim myself to be
>> good at it. So, feel free to adopt my suggestion if you like it or
>> ignore it otherwise.
>>
>> Reviewed-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> 
> Just noticed "trylock" in the #define SLAB_ALLOC_TRYLOCK
> 
> Please call it SLAB_ALLOC_NOLOCK.
> 
> Initial api was using 'trylock' name and it was a mistake,
> since people assumed normal spin_trylock() like semantics.
> "trylock" implies that it fails under contention
> and retry is a normal next step. It's not the case.
> No one should be retrying. That's why the final api was kmalloc_nolock().
> So please keep this important distinction in the name.
> SLAB_ALLOC_NOLOCK should mean that spinning locks
> should not be taken. It should not mean "just go to trylock everywhere".

Eh, ok then, will change to SLAB_ALLOC_NOLOCK. Even though it's mostly internal.

So next thing we change page allocator's ALLOC_TRYLOCK to ALLOC_NOLOCK too?