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

[Lorenzo Stoakes]

On Thu, May 21, 2026 at 01:40:03PM -0400, Waiman Long wrote:
> 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 at redhat.com>
> > > ---
> > >   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.

Haha herein lies the pain of naming - I am not claiming I am great at naming it
either :P

But _RT feels way off the mark for sure.

I mean in general, I'd rather we not add a new shall we say GFP flag alias? You
suggest an alternative approach in 2/2 so I'd definitely encourage you to
explore that first.

But if we were to add this, I'd prefer something like GFP_INTERRUPT or such? I
mean that's pretty terrible too... but something that points to the key feature
of being usable in contexts where preemption/interrupts are disabled.

>
> Cheers,
> Longman
>
>

Thanks, Lorenzo