[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d0f189b-faab-4452-b9cc-8f4e7a15025f@linux.alibaba.com>
Date: Fri, 6 Feb 2026 11:33:30 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...nel.org>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Zi Yan <ziy@...dia.com>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
Lance Yang <lance.yang@...ux.dev>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [stable-6.6.y] mm: khugepaged refuses to freeze
On 2/6/26 10:47 AM, Sergey Senozhatsky wrote:
> Greetings,
>
> I'm looking at a slightly unusual issue where khugepaged refuses to
> freeze 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
> ? sysvec_apic_timer_interrupt+0xf/0x90
> ? asm_sysvec_apic_timer_interrupt+0x16/0x20
> ? wait_for_completion_io_timeout+0xc5/0x170
> schedule_timeout+0x23b/0x6e0
> ? __pfx_process_timeout+0x10/0x10
> ? wait_for_completion_io_timeout+0xc5/0x170
> io_schedule_timeout+0x3f/0x80
> wait_for_completion_io_timeout+0xe4/0x170
> submit_bio_wait+0x79/0xc0
> swap_readpage+0x150/0x2d0
> ? __pfx_submit_bio_wait_endio+0x10/0x10
> swap_cluster_readahead+0x3be/0x750
> ? __pfx_workingset_update_node+0x10/0x10
> 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
> ? __pfx_khugepaged+0x10/0x10
> ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x38/0x50
> ? __pfx_kthread+0x10/0x10
> ret_from_fork_asm+0x1b/0x30
> </TASK>
> ...
>
> The system is using zram swap. I wonder if khugepaged should
> be suspend/freeze aware. Does something like below make sense?
> Or is the problem elsewhere?
>
> ---
> mm/khugepaged.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index eff9e3061925..fa6a018b20a8 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1894,6 +1894,9 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
> xas_set(&xas, index);
> folio = xas_load(&xas);
>
> + if (try_to_freeze())
> + goto xa_unlocked;
> +
> VM_BUG_ON(index != xas.xa_index);
> if (is_shmem) {
> if (!folio) {
Your analysis is reasonable. When the system is freezing, khugepaged is
still trying to swap-in shmem to collapse, which prevents the system
from entering suspend state. However, it’s not only shmem that will swap
in, collapsing anonymous folios may also trigger swap-in operations.
Therefore, I think we should skip all collapse scans for anonymous and
file pages in the main scan function khugepaged_do_scan() if the system
is attempting to freeze.
Some sample code is as follows:
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index fa1e57fd2c46..cfa7882585ad 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2560,9 +2560,18 @@ static void khugepaged_do_scan(struct
collapse_control *cc)
lru_add_drain_all();
while (true) {
+ bool was_frozen;
+
cond_resched();
- if (unlikely(kthread_should_stop()))
+ if (unlikely(kthread_freezable_should_stop(&was_frozen)))
+ break;
+
+ /*
+ * We can speed up thawing tasks if we don't call
khugepaged_scan_mm_slot()
+ * after returning from the refrigerator
+ */
+ if (was_frozen)
break;
spin_lock(&khugepaged_mm_lock);
Powered by blists - more mailing lists