Re: [PATCHv2] mm: khugepaged: make scan loops suspend aware

[Lance Yang <lance.yang@linux.dev>]

On 2026/2/12 17:10, David Hildenbrand (Arm) wrote:
> On 2/12/26 10:05, Sergey Senozhatsky wrote:
>> On (26/02/12 09:44), David Hildenbrand (Arm) wrote:
>> [..]
>>> If we're fixing an issue, we usually try to identify which commit 
>>> introduced the
>>> issue.
>>>
>>> For example, support for freezing was introduced in
>>>
>>> commit 878aee7d6b5504e01b9caffce080e792b6b8d090
>>> Author: Andrea Arcangeli <aarcange@redhat.com>
>>> Date:   Thu Jan 13 15:47:10 2011 -0800
>>>
>>>      thp: freeze khugepaged and ksmd
>>>      It's unclear why schedule friendly kernel threads can't be taken 
>>> away by
>>>      the CPU through the scheduler itself.  It's safer to stop them 
>>> as they can
>>>      trigger memory allocation, if kswapd also freezes itself to avoid
>>>      generating I/O they have too.
>>>
>>>
>>>
>>> Now that I am looking through the history, I find:
>>>
>>> commit b39ca208403c8f2c17dab1fbfef1f5ecaff25e53
>>> Author: Kevin Hao <haokexin@gmail.com>
>>> Date:   Wed Dec 20 07:17:53 2023 +0800
>>>
>>>      mm/khugepaged: remove redundant try_to_freeze()
>>>      A freezable kernel thread can enter frozen state during freezing 
>>> by either
>>>      calling try_to_freeze() or using wait_event_freezable() and its 
>>> variants.
>>>      However, there is no need to use both methods simultaneously.  The
>>>      freezable wait variants have been used in khugepaged_wait_work() 
>>> and
>>>      khugepaged_alloc_sleep(), so remove this redundant try_to_freeze().
>>>      I used the following stress-ng command to generate some memory 
>>> load on my
>>>      Intel Alder Lake board (24 CPUs, 32G memory).
>>>
>>>
>>> I wonder if that made the issue more likely to appear?
>>>
>>>
>>> Interestingly, we also had in the past:
>>>
>>> commit 1dfb059b9438633b0546c5431538a47f6ed99028
>>> Author: Andrea Arcangeli <aarcange@redhat.com>
>>> Date:   Thu Dec 8 14:33:57 2011 -0800
>>>
>>>      thp: reduce khugepaged freezing latency
>>>      khugepaged can sometimes cause suspend to fail, requiring that 
>>> the user
>>>      retry the suspend operation.
>>>
>>>
>>> So it's a recurring theme.
>>
>> Interesting, so 1dfb059b9438633 and 878aee7d6b5504e fixed real
>> problems "khugepaged can sometimes cause suspend to fail", but
>> I don't see what exactly b39ca208403c8f2 fixed.  Sounds more
>> like an "optimization"?
> 
> Yes, a cleanup. I wonder if it caused harm.
> 
>>
>>> Given that we only scan "khugepaged_pages_to_scan" pages/ptes/etc. 
>>> before going back to sleep,
>>> I wonder how that can take in your setup that long.
>>>
>>> Why does it end up taking something around 20 seconds in your setup?
>>
>> I only have bug reports at hands, I don't have a repro.  Can the fact
>> that swap reads require S/W decompression (zram) add enough latency?
> 
> I guess so. 20 seconds is still a lot.
> 
>>
>>> How is khugepaged_pages_to_scan set in your environment?
>>
>> Let me check.
>>
>> cat /sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan
>> 4096
>>
>> Hmm, doesn't sound too high.  Let me look more.
> 
> Yeah, that's not a lot of pages to scan. It's the default (8 * 
> HPAGE_PMD_NR)

Right. 4096 pages is not much to scan :)

This patch lets khugepaged be frozen between VMAs.

But if khugepaged is already collapsing when freeze starts, there
are two places without freeze checks that could take a bit long:

- __collapse_huge_page_swapin() loops 512 pages, calls do_swap_page()
   for each swap entry.

- collapse_file() loops 512 pages, calls shmem_get_folio(). If pages
   are swapped out, shmem_swapin_folio() is called.

Each swap-in can block for I/O. With multiple pages swapped out, the
cumulative time adds up.

Maybe we also need check points inside these loops to bail out early?

Cheers,
Lance