The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Kiryl Shutsemau <kirill@shutemov.name>
Cc: akpm@linux-foundation.org, david@kernel.org,
	nico.pache@linux.dev,  baolin.wang@linux.alibaba.com,
	baohua@kernel.org, dev.jain@arm.com, hughd@google.com,
	 lance.yang@linux.dev, liam@infradead.org, mhocko@suse.com,
	rppt@kernel.org,  ryan.roberts@arm.com, shuah@kernel.org,
	surenb@google.com, usama.arif@linux.dev,  vbabka@kernel.org,
	ziy@nvidia.com, usama.anjum@arm.com, agordeev@linux.ibm.com,
	 linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org,  kas@kernel.org
Subject: Re: [PATCH v4 02/19] selftests/mm: skip collapse_compound_extreme() where the PMD is too large
Date: Tue, 18 Aug 2026 10:22:28 +0100	[thread overview]
Message-ID: <aoQi1sHTO_mIQVFx@lucifer> (raw)
In-Reply-To: <20260815015901.1236937-3-kirill@shutemov.name>

On Sat, Aug 15, 2026 at 02:58:44AM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> collapse_compound_extreme() builds a PTE table full of distinct PTE-mapped
> compound pages by cycling hpage_pmd_nr fault-time THPs through mremap.  It
> therefore needs hpage_pmd_nr PMD-order allocations in a row.  That is fine
> at a 2M PMD (4K base pages) or a 32M one (16K).  A 512M PMD -- arm64 with
> 64K base pages -- makes each of those an order-13 allocation, which the
> allocator cannot reliably hand out even once, let alone 8192 times.
>
> The failure is not a quiet one: the case calls ksft_exit_fail_msg(), so the
> whole binary stops and every case after it is lost.
>
> Skip the case where the PMD is larger than 32M.  The MADV_COLLAPSE cases
> still cover PMD-order collapse on those configurations, and 4K and 16K
> PMDs are unaffected.
>
> Assisted-by: Claude-Code:claude-opus-5
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

Ah yeah again we are hit with the consequences of assumptions around PMD
size which do not apply for 64 KiB page size :)

Seems sensible to me so:

Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
>  tools/testing/selftests/mm/khugepaged.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
> index 6cfec2b940ac..dd924edd8557 100644
> --- a/tools/testing/selftests/mm/khugepaged.c
> +++ b/tools/testing/selftests/mm/khugepaged.c
> @@ -940,6 +940,16 @@ static void collapse_compound_extreme(struct collapse_context *c, struct mem_ops
>  	void *p;
>  	int i;
>
> +	/*
> +	 * The test needs hpage_pmd_nr PMD-order allocations, which is likely to
> +	 * fail for large PMD sizes.  Skip if the PMD size is over 32M.
> +	 */
> +	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++) {
> --
> 2.54.0
>

--
Cheers, Lorenzo

  reply	other threads:[~2026-08-18  9:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15  1:58 [PATCH v4 00/19] selftests/mm: improve khugepaged coverage Kiryl Shutsemau
2026-08-15  1:58 ` [PATCH v4 01/19] selftests/mm: raise the khugepaged test-case cap Kiryl Shutsemau
2026-08-18  9:11   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 02/19] selftests/mm: skip collapse_compound_extreme() where the PMD is too large Kiryl Shutsemau
2026-08-18  9:22   ` Lorenzo Stoakes (ARM) [this message]
2026-08-15  1:58 ` [PATCH v4 03/19] selftests/mm: scale khugepaged's collapse wait with the PMD size Kiryl Shutsemau
2026-08-18 10:04   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 04/19] selftests/mm: skip khugepaged page cache cases without a PMD folio Kiryl Shutsemau
2026-08-18 10:07   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 05/19] selftests/mm: make the swap cases' swapout reliable Kiryl Shutsemau
2026-08-18 10:11   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 06/19] selftests/mm: stop khugepaged during the MADV_COLLAPSE cases Kiryl Shutsemau
2026-08-18 10:12   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 07/19] selftests/mm: move is_backed_by_folio() into vm_util Kiryl Shutsemau
2026-08-18 10:14   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 08/19] selftests/mm: add folio-order check for address ranges Kiryl Shutsemau
2026-08-18 10:25   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 09/19] selftests/mm: add folio-order detection self-check Kiryl Shutsemau
2026-08-18 10:30   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 10/19] selftests/mm: add khugepaged completion barrier helper Kiryl Shutsemau
2026-08-18 10:34   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 11/19] selftests/mm: add order-parameterized khugepaged collapse cases Kiryl Shutsemau
2026-08-18 10:38   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 12/19] selftests/mm: parameterize the mixed-source collapse case by source order Kiryl Shutsemau
2026-08-18 10:47   ` Lorenzo Stoakes (ARM)
2026-08-15  1:58 ` [PATCH v4 13/19] selftests/mm: cover a shared-source collapse write race Kiryl Shutsemau
2026-08-15  1:58 ` [PATCH v4 14/19] selftests/mm: run every supported collapse order by default Kiryl Shutsemau
2026-08-15  1:58 ` [PATCH v4 15/19] selftests/mm: check that one khugepaged pass collapses one window Kiryl Shutsemau
2026-08-15  1:58 ` [PATCH v4 16/19] selftests/mm: add khugepaged race harness Kiryl Shutsemau
2026-08-15  1:58 ` [PATCH v4 17/19] selftests/mm: race collapse of windows with holes Kiryl Shutsemau
2026-08-15  1:59 ` [PATCH v4 18/19] selftests/mm: add memory-pressure threads to the khugepaged race harness Kiryl Shutsemau
2026-08-15  1:59 ` [PATCH v4 19/19] selftests/mm: zap whole PTE tables in " 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=aoQi1sHTO_mIQVFx@lucifer \
    --to=ljs@kernel.org \
    --cc=agordeev@linux.ibm.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=hughd@google.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=mhocko@suse.com \
    --cc=nico.pache@linux.dev \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=usama.anjum@arm.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