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

[Jing Wu <realwujing@gmail.com>]

From: Qiliang Yuan <realwujing@gmail.com>

On 7/29/26 16:00, Vlastimil Babka (SUSE) wrote:
> GFP_KERNEL can't really come up short in practice, at least for non-costly
> orders, which are considered "too small to fail". I don't see immediately
> what order is being allocated there.
> It might perhaps be looping inside the allocator without success if it has
> trouble reclaiming. Which usually means the userspace workload is
> overloading the system.

Good catch, and it made me go check: the mergeable-buffer path allocates
through get_a_page() -> alloc_page(gfp_mask), so it's order-0. You're
right that this shouldn't return outright failure - "still_empty" from
try_fill_recv(GFP_KERNEL) looping via HZ/2 reschedules was my framing,
not something I've confirmed against an actual trace. What we have is
an outcome-level observation: buffers run short and incoming packets
have nowhere to land during that window. I don't have instrumentation
that distinguishes "GFP_KERNEL returned failure" from "GFP_KERNEL took
a long time looping in reclaim before succeeding" - I shouldn't have
implied the former without checking, and I'll stop describing it that
way.

> So is it looping in the page allocator or returning failures with
> GFP_KERNEL? I guess the former otherwise there would be allocation warnings.
> Note that why this happens can be also 4.19-specific and not applicable
> today.

Agreed it's probably the former, for the reason you gave.

> If kswapd can save the day by being woken up earlier, then it doesn't
> sound like there's nothing to reclaim. But then it's puzzling me why the
> GFP_KERNEL attempts wouldn't work smoothly enough too.

I think this is right that kswapd isn't reclaiming anything a direct
reclaimer couldn't also reach - it's the same underlying mechanism, not
a separate capability. What the patch changes is timing: kswapd, once
boosted and woken, keeps working toward a higher target continuously in
the background, instead of each CPU handling its own RX queue only
doing reclaim reactively, synchronously, at the moment its own
allocation needs it. Under concurrent pressure across multiple queues
(which is the case in what we've seen - several CPUs hitting this at
once), that front-loaded, single-threaded reclaim may finish work that
would otherwise be duplicated or contended across multiple simultaneous
direct reclaimers. I'll say plainly this is a hypothesis about why the
timing helps, not something I've measured directly yet.

> Great, especially with a realistic workload. However I'd still worry that
> we're working around some old and long time fixed allocator deficiency
> from 4.19, unless it's demonstrated on mainline.

That's a fair worry, and it made me go check exactly what our 4.19 host
does and doesn't have, rather than treat it as a monolithic 2018
allocator. Two relevant mm fixes landed upstream since:

- c89cca307b20 ("net: skbuff: sprinkle more __GFP_NOWARN on ingress
  allocs", 2024-08) - suppresses the warn_alloc() print for this exact
  path. Our host does NOT have this backported, which is exactly why
  the 144 failures showed up as log lines at all.

- 281dd25c1a018 ("mm/page_alloc: let GFP_ATOMIC order-0 allocs access
  highatomic reserves", 2024-10) - lets ALLOC_NON_BLOCK (i.e. GFP_ATOMIC)
  order-0 requests fall back to the MIGRATE_HIGHATOMIC reserve, the same
  way ALLOC_OOM already could. This one you suggested and reviewed
  yourself. Our host DOES have this one backported.

So the 144 failures we cited were logged on a kernel that already had
your highatomic fallback fix in place - it's not the "already fixed
elsewhere" case for that specific mechanism. What it demonstrates is
that under sustained pressure, the (small, bounded) highatomic reserve
itself can still run out, at which point GFP_ATOMIC order-0 has nowhere
left to fall back to on the current attempt - which is exactly the
point where this patch's proactive kswapd boost would matter, since it
only ever helps subsequent attempts, never the one that's already
failing.

I can't make the same claim about the rest of page_alloc.c/reclaim -
there have been ~900 commits to that file since v4.19, and I'm not
going to pretend our host tracks all of them. But for the two fixes
that are specifically relevant to this failure mode, I now know
exactly which one we have and which one we don't, instead of guessing.
I'll still go reproduce this on current mainline rather than rest the
case on that host alone.

Qiliang