Re: [PATCH v11] mm/page_alloc: boost watermarks on atomic allocation failure

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

On 7/21/26 01:37, Andrew Morton wrote:
> On Mon, 20 Jul 2026 16:15:48 +0800 Qiliang Yuan <realwujing@gmail.com> wrote:
> 
>> Atomic allocations (GFP_ATOMIC) are prone to failure under heavy memory
>> pressure as they cannot enter direct reclaim.
>> 
>> Handle these failures by introducing a watermark boost mechanism for
>> atomic requests. Refactor boost_watermark() using an internal helper to
>> support both fragmentation and atomic paths. Apply zone-proportional
>> boosts (~0.1% of managed pages) for atomic allocations, while
>> decoupling it from watermark_boost_factor.
> 
> Thanks for persisting with this.
> 
> You didn't retain Vlastimil's Reviewed-by: from v8?

It was Acked-by: and I asked for it to be removed due [1] to significant
changes in v10, which was acknowleded [2] (thanks):

> This is very much a networking thing - they must have considered
> similar things.  But my not-very-energetic attempts to get input from
> networking people have thus far failed.

Yes it would have been useful to have their input.

>> This failure signature keeps recurring in production: a host running
>> a downstream 4.19 kernel logged 144 order-0 GFP_ATOMIC failures over a

I think first only in [2] and now here we learn it's motivated by failures
observed on a downstream 4.19 based kernel.

>> 4h15m window, all through the same NIC driver receive softirq path,
>> across several unrelated network-facing services on the box. This
>> confirms the underlying problem is real and ongoing.

... on a 4.19 (released in 2018) based kernel. There were many changes to
this area since then, some for highatomic allocations even very recently.
So it's necessary to demonstrate the problem exists today as well.

And it shouldn't exist in the form of "logged failures" anyway, thanks to
commits such as c89cca307b20 ("net: skbuff: sprinkle more __GFP_NOWARN on
ingress allocs") that use GFP_ATOMIC with __GFP_NOWARN. So it's not about
avoiding warnings anymore, but preventing fallbacks to non-irq contexts
(that those allocations AFAIK have) and probably thus rather demonstrating
how that improves performance and justifies the patch and risks that come
with it (these heurstics are unfortunately fraught with them).

> It does not by
>> itself measure this patch's effect, since the fix has not been
>> deployed on that fleet yet.

That makes the argument for this patch even worse, but also due to the
above, it wouldn't really be relevant to do that with that 4.19 based kernel
so I can advice not investing time into that.

So what we'd need is to demonstrate that current mainline has a problem and
how it's fixed. A synthetic reproducer suggested in [2] can however be
misleading in the form of apparently confirming that yes, increasing
watermarks by 10% can succeed 10% longer bursts of atomic allocations. But
that alone is not enough to justify this change.

> We'll of course be very interested in these results.  Do you know
> if/when they'll be available?
> 
> Anyway, let me get this into mm.git and linux-next so we can at least
> parallelize wider testing with ongoing review.

linux-next means mm-unstable? I don't think this should be headed for the
next merge window given the above.

[1] https://lore.kernel.org/all/e011c6a8-cda5-42ce-9d42-b23d1c81b26b@suse.cz/#t
[2] https://lore.kernel.org/all/20260720033804.3862547-1-realwujing@gmail.com/