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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Mon Jun 15, 2026 at 2:02 AM PDT, Vlastimil Babka (SUSE) wrote:
> On 6/15/26 04:16, Alexei Starovoitov wrote:
>> On Sun, Jun 14, 2026 at 7:01 PM Suren Baghdasaryan <surenb@google.com> wrote:
>>>
>>> On Thu, Jun 11, 2026 at 8:50 PM Hao Li <hao.li@linux.dev> 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@kernel.org>
>>> > > ---
>>> >
>>> > Reviewed-by: Hao Li <hao.li@linux.dev>
>>>
>>> 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@google.com>
>> 
>> 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?

yeah. Would be good to align as well.