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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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.

> 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?