Re: [PATCH v4 03/19] selftests/mm: scale khugepaged's collapse wait with the PMD size
From: Kiryl Shutsemau
Date: Sun Aug 23 2026 - 15:17:54 EST
On Tue, Aug 18, 2026 at 11:04:57AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Sat, Aug 15, 2026 at 02:58:45AM +0100, Kiryl Shutsemau wrote:
> > From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> >
> > wait_for_scan() gives every case the same three seconds, whatever the huge
> > page costs to build. collapse_full() asks for four of them: 8M at a 2M
> > PMD, but 2G at a 512M PMD -- arm64 with 64K base pages.
> >
> > Three seconds is thin at that size rather than generous. Across 80 runs of
> > collapse_full() on arm64 with 64K pages the wait was half a second in 73 of
> > them, with a tail to two seconds. The case has also timed out in a full
> > matrix run, reporting a failure for a collapse that was still going.
> >
> > Keep three seconds as the floor and add a second per 128M collapsed. A 2M
> > PMD is unchanged. A 512M PMD gets 19 seconds.
>
> Yikes that does make this run really slow for 64 KiB page size machines and a
> key aim in the selftests is that they don't take too egregiously long to run.
>
> Can this somehow be trimmed some other way?
It does not change how long the run takes.
The timeout is a ceiling on a poll loop, not a sleep: wait_for_scan()
breaks as soon as check_huge() sees the collapse, or as soon as
`full_scans` has advanced by two.
On arm64 with 64K pages the wait was half a second in 73 of 80 runs of
`collapse_full()`. The 19 seconds is spent only when two khugepaged
passes have not completed in that time, which is the case this patch
exists to stop reporting as a failure. This can happen on very big
machines with high memory usage or in an emulator. I use QEMU TCG for
testing on ARM.
I will put that in the changelog for v5, with the before and after
runtime of the whole `./khugepaged` run.
--
Kiryl Shutsemau / Kirill A. Shutemov