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

[Michal Hocko <mhocko@suse.com>]

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
without much of an explanation why this cannot be really handled in
other way. Have you even considered any options to pull the allocation
from within the raw spin lock section?

-- 
Michal Hocko
SUSE Labs