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)" <[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.
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/[email protected] Thanks, Zenghui
