From: Zenghui Yu <zenghui.yu@linux.dev>
To: linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com,
baolin.wang@linux.alibaba.com, liam@infradead.org,
nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com,
baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev,
kas@kernel.org, ljs@kernel.org, vbabka@kernel.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
"Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>,
Kiryl Shutsemau <kirill@shutemov.name>
Subject: [PATCH] selftests/mm: skip collapse_compound_extreme() on THP allocation failure
Date: Wed, 28 Oct 2026 18:01:19 +0800 [thread overview]
Message-ID: <20261028100119.11340-1-zenghui.yu@linux.dev> (raw)
From: "Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>
collapse_compound_extreme() needs hpage_pmd_nr PMD-order allocations in a
row, and it kills the whole test binary via ksft_exit_fail_msg() as soon as
one of them fails.
Gating the case by PMD size (commit b36bec6a01b1) -- the current workaround
for arm64 with 64K base pages, where a 512M PMD makes every construction
step an order-13 allocation -- is not enough: the case still dies below the
cutoff, e.g. on an arm64 VM with 16K base pages and 8G of RAM, where the
construction would need ~64G worth of PMD-order allocations.
Remove the PMD-size gating and treat a failure to allocate a huge page
during the construction as a skip: whether the allocator can hand out
that many PMD-order folios in a row depends on the memory available on
the machine, not on the kernel.
Suggested-by: Kiryl Shutsemau <kirill@shutemov.name>
Link: https://lore.kernel.org/all/atiQmWnz8zx2AKI7@thinkstation
Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
---
tools/testing/selftests/mm/khugepaged.c | 26 +++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index 1bc7acc66a46..e6151732b17c 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -953,23 +953,25 @@ static void collapse_compound_extreme(struct collapse_context *c, struct mem_ops
void *p;
int i;
- /*
- * This needs hpage_pmd_nr PMD-order allocations in a row, which the
- * allocator will not supply if the PMD is very large.
- */
- if (hpage_pmd_size > (32UL << 20)) {
- ksft_test_result_skip("%s: PMD too large for fault-time THP construction\n",
- __func__);
- return;
- }
-
p = ops->setup_area(1);
ksft_print_msg("Construct PTE page table full of different PTE-mapped compound pages\n");
for (i = 0; i < hpage_pmd_nr; i++) {
madvise(BASE_ADDR, hpage_pmd_size, MADV_HUGEPAGE);
ops->fault(BASE_ADDR, 0, hpage_pmd_size);
- if (!ops->check_huge(BASE_ADDR, hpage_pmd_size, 1, hpage_pmd_size))
- ksft_exit_fail_msg("Failed to allocate huge page\n");
+ if (!ops->check_huge(BASE_ADDR, hpage_pmd_size, 1, hpage_pmd_size)) {
+ /*
+ * Constructing the PTE table requires hpage_pmd_nr
+ * PMD-order allocations in a row. Whether the
+ * allocator can supply them depends on the memory
+ * available on the machine, not on the kernel: skip
+ * instead of failing the test run.
+ */
+ ops->cleanup_area(BASE_ADDR - i * page_size,
+ i * page_size + hpage_pmd_size);
+ ksft_test_result_skip("%s: Failed to allocate huge page\n",
+ __func__);
+ return;
+ }
madvise(BASE_ADDR, hpage_pmd_size, MADV_NOHUGEPAGE);
p = mremap(BASE_ADDR - i * page_size,
--
2.56.0
next reply other threads:[~2026-10-28 10:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 10:01 Zenghui Yu [this message]
2026-10-28 12:51 ` [PATCH] selftests/mm: skip collapse_compound_extreme() on THP allocation failure Kiryl Shutsemau
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=20261028100119.11340-1-zenghui.yu@linux.dev \
--to=zenghui.yu@linux.dev \
--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=kas@kernel.org \
--cc=kirill@shutemov.name \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nico.pache@linux.dev \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--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