Re: [PATCH 1/2] gfp_types: Introduce a new GFP_ATOMIC_RT gfp flag

[Waiman Long]

On 5/21/26 12:40 PM, Lorenzo Stoakes wrote:
> +cc Matthew who has fairly strong opinions on GFP flags and such :)
>
> Also, please don't send 2 patch series with 2/2 in-reply-to 1/2, use a
> cover letter + have patches reply to that :) [yes it's one of those
> subjective things that people differ on a lot but generally how we do in
> mm]
>
> On Wed, May 20, 2026 at 04:46:27PM -0400, Waiman Long wrote:
> > The GFP_ATOMIC flag is to be used in atomic context where user cannot
> > sleep and need the allocation to succeed. However, it does not support
> > contexts where preemption or interrupt is disabled under PREEMPT_RT
> > like raw_spin_lock_irqsave() or plain preempt_disable().
> >
> > With the advance of the ALLOC_TRYLOCK allocation flag in the v7.1
> > kernel, it is possible to allocate memory under such contexts by using
> > spin_trylock to acquire the spinlock in the memory allocation path. This
> > does increase the chance that the allocation can fail due to the presence
> > of concurrent memory allocation requests. So its users must be able to
> > handle such memory allocation failure gracefully.
> >
> > The ALLOC_TRYLOCK flag will only be enabled if none of the
> > ___GFP_DIRECT_RECLAIM and ___GFP_KSWAPD_RECLAIM flags are set.
> >
> > Introduce a new GFP_ATOMIC_RT gfp flag for those PREEMPT_RT
> > atomic contexts.  This new flag will fall back to GFP_ATOMIC in
> > non-PREEMPT_RT kernel. GFP_ATOMIC can continue to be used in contexts
> > where preemption and interrupt are not disabled in PREEMPT_RT kernel
> > like spin_lock_irqsave().
> This seems like the wrong place for the solution, now we have to remember
> to use a specific GFP flag but only in one specific place in some IRQ code,
> yet RT is fine with this in any other scenario?
>
> This is really confusing.
>
> Wouldn't we better off with a way of actively detecting this context
> somehow in the page allocator?

This new GFP_ATOMIC_RT flag will make memory allocation more likely to 
fail compared with GFP_ATOMIC. That is the main reason why I think a 
separate flag with documentation about this difference will make the 
users of the new gfp flag more aware of what they should check before 
they use it.

I would certainly like to have the mm memory allocation code to handle 
it automatically if it doesn't impact the failure rate.

> It just instinctively feels like this is the wrong level of abstraction for
> a fix here :)
With PREEMPT_RT, GFP_ATOMIC_RT just translates to __GFP_HIGH. It can be 
set explicitly in the relevant call sites. This patch is more a 
documentation step to make clear the purpose and consequence of doing that.
> > Signed-off-by: Waiman Long <longman@xxxxxxxxxx>
> > ---
> >   include/linux/gfp_types.h | 13 +++++++++++++
> >   1 file changed, 13 insertions(+)
> >
> > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> > index cd4972a7c97c..ac30882b6cd4 100644
> > --- a/include/linux/gfp_types.h
> > +++ b/include/linux/gfp_types.h
> > @@ -316,6 +316,13 @@ enum {
> >    * preempt_disable() - see "Memory allocation" in
> >    * Documentation/core-api/real-time/differences.rst for more info.
> >    *
> > + * %GFP_ATOMIC_RT is similar to %GFP_ATOMIC with the addition that it can also
> > + * be used in context where preemption and/or interrupt is disabled under
> > + * PREEMPT_RT, but not in NMI or hardirq contexts. The allocation is more
> I'm not sure 'GFP_ATOMIC_RT' really communicates all of this information.

I am not good at naming. If you have other good suggestion, I would like 
to hear it.

Cheers,
Longman