Re: [PATCH v6 02/19] selftests/mm: skip collapse_compound_extreme() where the PMD is too large

[Zenghui Yu]

Hi Kiryl,

On 10/21/26 6:32 PM, Kiryl Shutsemau wrote:
> On Thu, Oct 08, 2026 at 07:52:18PM +0800, Zenghui Yu wrote:
> > Hi Kiryl,
> >
> > On 9/19/26 8:24 AM, Kiryl Shutsemau wrote:
> > > From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> > >
> > > 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.
> >
> > collapse_compound_extreme() failed on an arm64 virtual machines with 16k
> > pages.  The VM has 8GB of memory.  Not sure if this is the same issue that
> > this patch attempts to address.
> 
> It is the same issue.
> 
> Memory usage for the test case, assuming 64-bit page table entries:
> 
>          4K pages:  512 x   2M =  1G
>         16K pages: 2048 x  32M = 64G
>         64K pages: 8192 x 512M =  4T
> 
> 64G is a lot, but I don't think we want to give up on this test case
> on 16k machines completely.

Agreed. This test case passed on other arm64 servers with sufficient
memory.

> Maybe we should treat a failure to allocate a huge page here as a skip,
> not a fail? And remove the PMD-size gating.
> 
> Zenghui, do you want to experiment with this?

I've just sent a patch for that. Thanks for your suggestion.

https://lore.kernel.org/20261028100119.11340-1-zenghui.yu@xxxxxxxxx

Thanks,
Zenghui