From: Nimrod Oren <noren@nvidia.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <npache@redhat.com>,
"Ryan Roberts" <ryan.roberts@arm.com>,
Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Liu Song <liusong@linux.alibaba.com>,
Hao Peng <flyingpenghao@gmail.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Nimrod Oren <noren@nvidia.com>
Subject: [RFC PATCH] mm/khugepaged: cap pageblock contribution to min_free_kbytes
Date: Thu, 16 Jul 2026 20:35:04 +0300 [thread overview]
Message-ID: <20260716173504.760369-1-noren@nvidia.com> (raw)
When THP is enabled, khugepaged can raise min_free_kbytes through
set_recommended_min_free_kbytes(), using a heuristic that scales with
pageblock_nr_pages. With MIGRATE_PCPTYPES equal to 3, the formula
accounts for 11 pageblocks for every eligible populated zone before
capping the result at 5% of low memory.
This is reasonable when a pageblock is 2MB, as on common 4KB page
configurations, but scales poorly with larger base page sizes. With
the default arm64 pageblock sizes, the contribution per eligible zone
before the 5% cap is:
4KB pages: 2MB pageblock, 22MB per zone
16KB pages: 32MB pageblock, 352MB per zone
64KB pages: 512MB pageblock, 5.5GB per zone
The 5% limit does not make this harmless. On an arm64 system with
128GB of RAM and 64KB pages, the current calculation resulted in
roughly 6.3GB for min_free_kbytes. The corresponding aggregate min, low
and high watermarks were 6.3GB, 7.8GB and 9.4GB.
Automatically maintaining multiple GB of additional free memory to
improve the probability of 512MB THP allocations seems disproportionate
for an opportunistic background optimization.
This RFC proposes capping the pageblock contribution to the
recommendation at 2MB. This would limit the contribution to 22MB per
eligible zone while leaving configurations with pageblocks of 2MB or
smaller unchanged.
Earlier proposals to resolve this problem involved disabling default
THP on affected systems [1], adding a knob to disable the
recommendation [2], or deriving the recommendation from the largest
enabled THP order [3]. A fixed cap requires no new knob and avoids
large changes to global watermarks when THP policy is changed at
runtime.
Reducing PAGE_BLOCK_MAX_ORDER remains possible, but it is a build-time
policy that changes pageblock granularity globally. Its effects extend
beyond the scope of adjusting min_free_kbytes.
[1] https://lore.kernel.org/all/CAPm50aLPxJCiVTqqwiz00oMNiqHggB84sXB3x=tv_HUAd5UktQ@mail.gmail.com/
[2] https://lore.kernel.org/all/20230817035155.84230-1-liusong@linux.alibaba.com/
[3] https://lore.kernel.org/all/20250606143700.3256414-1-usamaarif642@gmail.com/
Signed-off-by: Nimrod Oren <noren@nvidia.com>
---
mm/khugepaged.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 27e8f3077e80..c0570bbb1f4e 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -23,6 +23,7 @@
#include <linux/ksm.h>
#include <linux/pgalloc.h>
#include <linux/backing-dev.h>
+#include <linux/sizes.h>
#include <asm/tlb.h>
#include "internal.h"
@@ -3066,6 +3067,7 @@ void set_recommended_min_free_kbytes(void)
{
struct zone *zone;
int nr_zones = 0;
+ unsigned long capped_pageblock_nr_pages;
unsigned long recommended_min;
if (!hugepage_enabled()) {
@@ -3084,16 +3086,23 @@ void set_recommended_min_free_kbytes(void)
nr_zones++;
}
- /* Ensure 2 pageblocks are free to assist fragmentation avoidance */
- recommended_min = pageblock_nr_pages * nr_zones * 2;
+ /*
+ * Limit the pageblock contribution to 2 MiB. Larger pageblocks can
+ * otherwise make min_free_kbytes disproportionately large.
+ */
+ capped_pageblock_nr_pages =
+ min(pageblock_nr_pages, SZ_2M / PAGE_SIZE);
+
+ /* Ensure 2 capped units are free to assist fragmentation avoidance */
+ recommended_min = capped_pageblock_nr_pages * nr_zones * 2;
/*
- * Make sure that on average at least two pageblocks are almost free
+ * Make sure that on average at least two capped units are almost free
* of another type, one for a migratetype to fall back to and a
* second to avoid subsequent fallbacks of other types There are 3
* MIGRATE_TYPES we care about.
*/
- recommended_min += pageblock_nr_pages * nr_zones *
+ recommended_min += capped_pageblock_nr_pages * nr_zones *
MIGRATE_PCPTYPES * MIGRATE_PCPTYPES;
/* don't ever allow to reserve more than 5% of the lowmem */
--
2.45.0
next reply other threads:[~2026-07-16 17:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 17:35 Nimrod Oren [this message]
2026-07-17 13:36 ` [RFC PATCH] mm/khugepaged: cap pageblock contribution to min_free_kbytes Lorenzo Stoakes (ARM)
2026-07-17 14:58 ` Zi Yan
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=20260716173504.760369-1-noren@nvidia.com \
--to=noren@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=flyingpenghao@gmail.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liusong@linux.alibaba.com \
--cc=ljs@kernel.org \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.