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 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.