> 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,

collapse_full() please

> 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, and the case has 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 to collapse.  A
> 2M PMD is unchanged.  A 512M PMD gets 19 seconds, which is headroom over
> the observed tail rather than a measured requirement.  The budget bounds
> how long a real failure takes to report, not how long a passing case
> waits: wait_for_scan() returns as soon as the collapse turns up.
> 
> arm64/64K: khugepaged all:anon 21 pass/1 fail -> 22 pass/0 fail.  x86-64 is
> unchanged.
> 
> Assisted-by: Claude-Code:claude-opus-5
> Tested-by: Muhammad Usama Anjum <[email protected]>
> Signed-off-by: Kiryl Shutsemau (Meta) <[email protected]>
>
> diff --git a/tools/testing/selftests/mm/khugepaged.c 
> b/tools/testing/selftests/mm/khugepaged.c
> index 48eb74c255f6..a5ada78d90ee 100644
> --- a/tools/testing/selftests/mm/khugepaged.c
> +++ b/tools/testing/selftests/mm/khugepaged.c
> @@ -583,8 +583,10 @@ static bool wait_for_scan(const char *msg, char *p, 
> size_t len,
>               int nr_hpages, int collap_order, struct mem_ops *ops)
>  {
>       unsigned long hpage_size = page_size << collap_order;
> +     /* Three seconds as a floor, plus a second per 128M to collapse */
> +     const unsigned long bytes = (unsigned long)nr_hpages * hpage_size;
> +     int timeout = 6 + 2 * (bytes / (128UL << 20));
>       int full_scans;
> -     int timeout = 6; /* 3 seconds */

It's a pity we lost the comment explainging that timeout is seconds x2

>  
>       /* Sanity check */
>       if (!ops->check_huge(p, len, 0, hpage_size))

Reviewed-by: Mike Rapoport (Microsoft) <[email protected]>

-- 
Sincerely yours,
Mike.


Reply via email to