Re: [PATCH v4 03/19] selftests/mm: scale khugepaged's collapse wait with the PMD size

[Kiryl Shutsemau <kirill@shutemov.name>]

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@kernel.org>
> >
> > 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