From: wujing <realwujing@qq.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
Lance Yang <lance.yang@linux.dev>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Brendan Jackman <jackmanb@google.com>,
Suren Baghdasaryan <surenb@google.com>, Zi Yan <ziy@nvidia.com>,
Mike Rapoport <rppt@kernel.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
linux-mm@kvack.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, wujing <realwujing@qq.com>
Subject: [PATCH v4 0/1] mm/page_alloc: auto-tune watermarks on atomic allocation failure
Date: Tue, 6 Jan 2026 14:19:49 +0800 [thread overview]
Message-ID: <tencent_B8B6D067EF7417B3B0D3DCC1A01505453F05@qq.com> (raw)
wujing (1):
mm/page_alloc: auto-tune watermarks on atomic allocation failure
include/linux/mmzone.h | 2 ++
mm/page_alloc.c | 55 +++++++++++++++++++++++++++++++++++++++---
Hi Andrew, Vlastimil, Michal, and others,
This is v4 of the patch to introduce reactive auto-tuning for GFP_ATOMIC
allocations. This version incorporates significant architectural
refinements based on feedback from Michal Hocko and the community.
### Addressing Michal Hocko's Feedback (v3 -> v4):
1. "Reactive is too late":
Michal correctly noted that boosting only after failure is
sub-optimal for non-sleepable contexts.
-> v4 introduces **Proactive Soft-Boosting**. When a GFP_ATOMIC request
enters the slowpath but has not yet failed, a lightweight boost is
triggered, replenishing reserves *before* exhaustion occurs.
2. "Use watermark_scale_factor instead of complex knobs":
Michal suggested that scaling the reclaim aggressiveness is more
idiomatic than just boosting the watermarks.
-> v4 implements **Hybrid Tuning**. We now introduce
`zone->watermark_scale_boost`. When pressure is detected, we not
only boost the base watermark (via boost_watermark) but also
temporarily increase the recovery aggressiveness (via scaling).
3. "Smooth transition":
There were concerns about the "cliff-edge" effect of resetting tuning
parameters instantly.
-> v4 implements **Gradual Decay** for the scale boost (-5 per
kswapd cycle), ensuring a stable fallback to the baseline.
### Core v4 Optimizations:
1. Per-Zone Debounce: Moved the 10s debounce timer to struct zone to
ensure independent pressure responses across NUMA nodes.
2. Scaled Boosting Intensity: Boost strength is now dynamically scaled
by ~0.1% of managed pages, ensuring TB-scale systems get a
meaningful response.
3. Precision Pathing: Both failure-path and proactive boosts now only
target the preferred zone (precision break) to prevent unnecessary
background reclaim overhead.
4. Strict Bitmask Verification: Tightened the tuning trigger to a
strict (gfp_mask & GFP_ATOMIC) == GFP_ATOMIC check to focus solely
on mission-critical allocations.
Testing in simulated burst environments shows that the combination of
proactive boosting and hybird scaling provides a significantly
more robust defense against packet drops than simple reactive boosting alone.
Special thanks to Vlastimil Babka, Andrew Morton, Matthew Wilcox, Lance Yang,
and Michal Hocko for the foundational critiques that led to this design.
Thanks for the reviews!
---
wujing (1):
mm/page_alloc: auto-tune watermarks on atomic allocation failure
include/linux/mmzone.h | 2 ++
mm/page_alloc.c | 55 +++++++++++++++++++++++++++++++++++++++---
mm/vmscan.c | 10 ++++++++
3 files changed, 64 insertions(+), 3 deletions(-)
--
2.39.5
reply other threads:[~2026-01-06 6:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tencent_B8B6D067EF7417B3B0D3DCC1A01505453F05@qq.com \
--to=realwujing@qq.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=netdev@vger.kernel.org \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox