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)" <[email protected]>
> >
> > 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
