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

[Kiryl Shutsemau]

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.

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?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov