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. [root@localhost mm]# ./khugepaged [ snipped ] # # Run test: collapse_full_of_compound (madvise:anon) # Allocate huge page... OK # Split huge page leaving single PTE page table full of compound pages... OK # Collapse PTE table full of compound pages... OK ok 76 collapse_full_of_compound # # Run test: collapse_compound_extreme (khugepaged:anon) # Construct PTE page table full of different PTE-mapped compound pages Bail out! Failed to allocate huge page # 1 skipped test(s) detected. Consider enabling relevant config options to improve coverage. # Planned tests != run tests (91 != 76) # Totals: pass:75 fail:0 xfail:0 xpass:0 skip:1 error:0 Thanks, Zenghui
