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

[Michal Hocko <mhocko@suse.com>]

On Tue 26-05-26 15:55:09, Vlastimil Babka (SUSE) wrote:
> On 5/25/26 10:41 AM, Michal Hocko wrote:
> > On Wed 20-05-26 16:46:27, 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().
> > 
> > Before we go this way we need to really be clear we do want to support
> > raw_spinlock (aka RT) contexts. This is a big commitment because it
> > dictates internal allocator locking that would have potentially a much
> > bigger impact long term. I would go this way only after/when we conclude
> > there is absolutely no other way and we need to have allocator in those
> > critical sections. Now you have a single place which complains ATM
> 
> We already have alloc_pages_nolock() which uses ALLOC_TRYLOCK internally
> for these limited contexts. So the support and commitment exist. This
> just exposes it via a new gfp flag alias. But if there's a single user
> and it's already disputed, we don't have to expose it that way indeed.

alloc_pages_nolock is a very constrained allocation context with a very
limited use. That is quite different from something as generically named
as GFP_ATOMIC_RT that one could assume is a good fit for RT sensitive
allocations in general.

-- 
Michal Hocko
SUSE Labs