Re: [PATCH] mm/khugepaged: Fix skipping of alloc sleep after second failure

[Lance Yang]

On 2025/11/24 17:14, David Hildenbrand (Red Hat) wrote:
> On 11/24/25 07:19, Zhiheng Tao wrote:
> > In khugepaged_do_scan(), two consecutive allocation failures cause
> > the logic to skip the dedicated 60s throttling sleep
> > (khugepaged_alloc_sleep_millisecs), forcing a fallback to the
> > shorter 10s scanning interval via the outer loop
> >
> > Since fragmentation is unlikely to resolve in 10s, this results in
> > wasted CPU cycles on immediate retries.
>
> Why shouldn't memory comapction be able to compact a single THP in 10s?
>
> Why should it resolve in 60s?
>
> > Reorder the failure logic to ensure khugepaged_alloc_sleep() is
> > always called on each allocation failure.
> >
> > Fixes: c6a7f445a272 ("mm: khugepaged: don't carry huge page to the 
> > next loop for !CONFIG_NUMA")
>
> What are we fixing here? This sounds like a change that might be better 
> on some systems, but worse on others?

Seems like we're not honoring khugepaged_alloc_sleep_millisecs on the
second allocation failure... but is that actually a problem?

> We really need more information on when/how an issue was hit, and how 
> this patch here really moves the needle in any way.

+1