> On Tue, 15 Sep 2026 10:21:35 +0100 Yeoreum Yun <[email protected]> wrote: > > > There are intermittent failures in collapse_max_ptes_swap() and > > collapse_max_ptes_shared() when using the khugepaged_context: > > > > # Run test: collapse_max_ptes_shared (khugepaged:anon) > > # Allocate huge page... OK > > # Share huge page over fork()... OK > > # Trigger CoW on page 1023 of 2048... OK > > # Maybe collapse with max_ptes_shared exceeded.... OK > > # Trigger CoW on page 1024 of 2048... Fail > > Bail out! Unexpected huge page > > # Planned tests != run tests (26 != 23) > > # Totals: pass:23 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > # Run test: collapse_max_ptes_swap (khugepaged:anon) > > # Swapout 257 of 2048 pages... OK > > # Maybe collapse with max_ptes_swap exceeded.... OK > > # Swapout 256 of 2048 pages... OK > > Bail out! Unexpected huge page > > # Planned tests != run tests (26 != 17) > > # Totals: pass:17 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > This happens because khugepaged may collapse the pages before > > wait_for_scan() > > is called, causing a sanity check that expects uncollapsed pages to fail. > > Is this something we should be testing for? If I'm understanding > correctly, success/failure is dependent on timing vargaries inside the > kernel and that isn't something we can reliably test for. > > IOW, should we say "bad idea" and just delete this test case?
If the test environment can be set up to control those timing vagaries, I believe in that such cases are meaningful for verifying the expected behavior. This patch sets up the conditions needed to make the result reliable, so I don't think this test case should be dismissed as a bad idea or deleted as inherently unreliable. -- Sincerely, Yeoreum Yun
