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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 2/12/26 07:32, Sergey Senozhatsky wrote:
> On (26/02/11 10:50), David Hildenbrand (Arm) wrote:
>> On 2/11/26 04:15, Sergey Senozhatsky wrote:
>>> A number of khugepaaged's loops, e.g. khugepaged_scan_mm_slot(),
>>> are time unbound, which can become problematic during system
>>> suspend:
>>>
>>> PM: suspend entry (s2idle)
>>> Filesystems sync: 0.003 seconds
>>> Freezing user space processes
>>> Freezing user space processes completed (elapsed 0.003 seconds)
>>> OOM killer disabled.
>>> Freezing remaining freezable tasks
>>> Freezing remaining freezable tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>>> task:khugepaged      state:D stack:0     pid:1345  ppid:2      flags:0x00004000
>>> Call Trace:
>>>    <TASK>
>>>    schedule+0x523/0x16a0
>>>    schedule_timeout+0x23b/0x6e0
>>>    io_schedule_timeout+0x3f/0x80
>>>    wait_for_completion_io_timeout+0xe4/0x170
>>>    submit_bio_wait+0x79/0xc0
>>>    swap_readpage+0x150/0x2d0
>>>    swap_cluster_readahead+0x3be/0x750
>>>    shmem_swapin+0xa7/0x100
>>>    shmem_swapin_folio+0xcd/0x2e0
>>>    shmem_get_folio+0x237/0x580
>>>    collapse_file+0x247/0x1280
>>>    hpage_collapse_scan_file+0x26e/0x380
>>>    khugepaged+0x43b/0x810
>>>    kthread+0xfb/0x120
>>>    </TASK>
>>>
>>> Make hpage_collapse_test_exit_or_disable() suspend aware so
>>> that khugepaaged's scan loops can terminate in a timely manner
>>> and let system enter the sleep state.
>>>
>>
>> Do we want a Fixes: tag, and maybe backport this to stable kernels?
> 
> I can Cc stable, but I don't know about Fixes - we are adding something
> that was never there, not fixing a regression.

Cc: stable is only possible with a valid Fixes:.

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.


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? How is khugepaged_pages_to_scan
set in your environment?


-- 
Cheers,

David