From: Bo Zhang <zhangbo0325@gmail.com>
To: akpm@linux-foundation.org, vbabka@kernel.org, david@kernel.org
Cc: surenb@google.com, mhocko@suse.com, brendan.jackman@linux.dev,
hannes@cmpxchg.org, ziy@nvidia.com, ljs@kernel.org,
liam@infradead.org, rppt@kernel.org, qi.zheng@linux.dev,
shakeel.butt@linux.dev, kasong@tencent.com, baohua@kernel.org,
axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com,
zhaonanzhe@xiaomi.com, lipengfei28@xiaomi.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Bo Zhang <zhangbo56@xiaomi.com>
Subject: [RFC PATCH 1/4] mm: compaction: make proactive compaction mTHP-aware
Date: Tue, 25 Aug 2026 12:38:30 +0800 [thread overview]
Message-ID: <20260825043833.2659350-2-zhangbo56@xiaomi.com> (raw)
In-Reply-To: <20260825043833.2659350-1-zhangbo56@xiaomi.com>
Currently, proactive compaction only evaluates fragmentation relative
to COMPACTION_HPAGE_ORDER (typically order-9 for 2MB THP). This makes
it unsuitable for systems that primarily need smaller high-order pages,
such as order-2 (16KB) for mTHP.
Generalize the fragmentation score functions to accept an order parameter:
- fragmentation_score_zone(zone, order)
- fragmentation_score_zone_weighted(zone, order)
- fragmentation_score_node(pgdat, order)
Calculate the min order in huge_anon_orders_always to configure the target
order for proactive compaction.
This enables proactive compaction to maintain free page availability
at any order, which is particularly useful for mTHP-enabled systems
where order-n (n < 9) allocation pressure is high.
Signed-off-by: Bo Zhang <zhangbo56@xiaomi.com>
---
mm/compaction.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index a049415512c6..a4f87232ad80 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -24,6 +24,7 @@
#include <linux/page_owner.h>
#include <linux/psi.h>
#include <linux/cpuset.h>
+#include <linux/huge_mm.h>
#include "page_alloc.h"
#include "internal.h"
@@ -81,6 +82,15 @@ static inline bool is_via_compact_memory(int order) { return false; }
#define COMPACTION_HPAGE_ORDER (PMD_SHIFT - PAGE_SHIFT)
#endif
+static inline int compact_hpage_order(void)
+{
+ unsigned long orders = READ_ONCE(huge_anon_orders_always);
+
+ if (orders)
+ return __ffs(orders);
+ return COMPACTION_HPAGE_ORDER;
+}
+
static struct page *mark_allocated_noprof(struct page *page, unsigned int order, gfp_t gfp_flags)
{
post_alloc_hook(page, order, __GFP_MOVABLE, ALLOC_DEFAULT);
@@ -2208,16 +2218,16 @@ static bool kswapd_is_running(pg_data_t *pgdat)
/*
* A zone's fragmentation score is the external fragmentation wrt to the
- * COMPACTION_HPAGE_ORDER. It returns a value in the range [0, 100].
+ * compact_hpage_order(). It returns a value in the range [0, 100].
*/
-static unsigned int fragmentation_score_zone(struct zone *zone)
+static unsigned int fragmentation_score_zone(struct zone *zone, unsigned int order)
{
- return extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
+ return extfrag_for_order(zone, order);
}
/*
* A weighted zone's fragmentation score is the external fragmentation
- * wrt to the COMPACTION_HPAGE_ORDER scaled by the zone's size. It
+ * wrt to the compact_hpage_order() scaled by the zone's size. It
* returns a value in the range [0, 100].
*
* The scaling factor ensures that proactive compaction focuses on larger
@@ -2225,11 +2235,11 @@ static unsigned int fragmentation_score_zone(struct zone *zone)
* ZONE_DMA32. For smaller zones, the score value remains close to zero,
* and thus never exceeds the high threshold for proactive compaction.
*/
-static unsigned int fragmentation_score_zone_weighted(struct zone *zone)
+static unsigned int fragmentation_score_zone_weighted(struct zone *zone, unsigned int order)
{
unsigned long score;
- score = zone->present_pages * fragmentation_score_zone(zone);
+ score = zone->present_pages * fragmentation_score_zone(zone, order);
return div64_ul(score, zone->zone_pgdat->node_present_pages + 1);
}
@@ -2240,7 +2250,7 @@ static unsigned int fragmentation_score_zone_weighted(struct zone *zone)
* the node's score falls below the low threshold, or one of the back-off
* conditions is met.
*/
-static unsigned int fragmentation_score_node(pg_data_t *pgdat)
+static unsigned int fragmentation_score_node(pg_data_t *pgdat, unsigned int order)
{
unsigned int score = 0;
int zoneid;
@@ -2251,7 +2261,7 @@ static unsigned int fragmentation_score_node(pg_data_t *pgdat)
zone = &pgdat->node_zones[zoneid];
if (!populated_zone(zone))
continue;
- score += fragmentation_score_zone_weighted(zone);
+ score += fragmentation_score_zone_weighted(zone, order);
}
return score;
@@ -2269,12 +2279,13 @@ static unsigned int fragmentation_score_wmark(bool low)
static bool should_proactive_compact_node(pg_data_t *pgdat)
{
int wmark_high;
+ unsigned int order = compact_hpage_order();
if (!sysctl_compaction_proactiveness || kswapd_is_running(pgdat))
return false;
wmark_high = fragmentation_score_wmark(false);
- return fragmentation_score_node(pgdat) > wmark_high;
+ return fragmentation_score_node(pgdat, order) > wmark_high;
}
static enum compact_result __compact_finished(struct compact_control *cc)
@@ -2311,7 +2322,7 @@ static enum compact_result __compact_finished(struct compact_control *cc)
if (kswapd_is_running(pgdat))
return COMPACT_PARTIAL_SKIPPED;
- score = fragmentation_score_zone(cc->zone);
+ score = fragmentation_score_zone(cc->zone, compact_hpage_order());
wmark_low = fragmentation_score_wmark(true);
if (score > wmark_low)
@@ -3238,10 +3249,11 @@ static int kcompactd(void *p)
timeout = default_timeout;
if (should_proactive_compact_node(pgdat)) {
unsigned int prev_score, score;
+ unsigned int order = compact_hpage_order();
- prev_score = fragmentation_score_node(pgdat);
+ prev_score = fragmentation_score_node(pgdat, order);
compact_node(pgdat, true);
- score = fragmentation_score_node(pgdat);
+ score = fragmentation_score_node(pgdat, order);
/*
* Defer proactive compaction if the fragmentation
* score did not go down i.e. no progress made.
--
2.34.1
next prev parent reply other threads:[~2026-08-25 4:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 4:38 [RFC PATCH 0/4] mm: compaction: mTHP-friendly memory compaction Bo Zhang
2026-08-25 4:38 ` Bo Zhang [this message]
2026-09-03 14:11 ` [RFC PATCH 1/4] mm: compaction: make proactive compaction mTHP-aware Bo Zhang
2026-08-25 4:38 ` [RFC PATCH 2/4] mm: compaction: skip isolating large folios that satisfy the mTHP order Bo Zhang
2026-09-03 14:29 ` Bo Zhang
2026-08-25 4:38 ` [RFC PATCH 3/4] mm: compaction: don't skip proactive compaction for non-costly mTHP Bo Zhang
2026-09-03 14:32 ` Bo Zhang
2026-08-25 4:38 ` [RFC PATCH 4/4] mm: adjust free_pages to make __zone_watermark_ok() mTHP-aware Bo Zhang
2026-09-03 2:46 ` Xueyuan Chen
2026-09-03 13:56 ` Bo Zhang
2026-09-03 15:09 ` Bo Zhang
2026-09-07 2:51 ` [RFC PATCH 0/4] mm: compaction: mTHP-friendly memory compaction Zi Yan
2026-09-07 8:45 ` Bo Zhang
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=20260825043833.2659350-2-zhangbo56@xiaomi.com \
--to=zhangbo0325@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=brendan.jackman@linux.dev \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lipengfei28@xiaomi.com \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhangbo56@xiaomi.com \
--cc=zhaonanzhe@xiaomi.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