From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A6F0265CC2 for ; Fri, 6 Feb 2026 03:33:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770348816; cv=none; b=nh+FxVj5+r/n9tNaI+2b0CQH1VGngHY1lFbdxEMbWEOx9/1v5o93JsxSHzWQEkyGXc1L6wvYJOtaUj61RTk8weKS73c0IMoC0urL1QgGEuTTDK4k6vSR6Sht5v33JTACKrJ3PshMfQT6Tp0Sp4pIXc2XX4ElurqN0kHhTBdVqKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770348816; c=relaxed/simple; bh=uXx5haZe8kHtRPYHLoH/vFIaebngGiyJKZDTexZjeFM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jAU4jMFLsEA61S/I8zuq0nTgUdCVbQV317jO6uEQrV3FyDuGx8OwuUaZsfZvmtxdGCJzGWpqsdYkVtHrJ7o4CuVqF6dhIwLsB6q0qNeLqalkSpHQZWF9L1wZZWO7qoBGQZopbeWI9N/rO888mrepc2CCWakNbVKKMPsWIOGjXDc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=FSVjtIr2; arc=none smtp.client-ip=115.124.30.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="FSVjtIr2" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1770348813; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=nfwuNC8piLwTY/hUFLM5kDRlEuRZjguUamVqe3iMLTU=; b=FSVjtIr2sp9W9nibQmanf53pzYlM0PA2lHVQR+YFTOSeTzYJDSKcVnuvr5+R+VUpZnpmpQbb26vvEbky6SE618w6XmS5qn9a0DqTTLNokL7ClmtAUbj65ylUlU2dIv3OMXDLEXdgNfdnda0WKP5zt/Z+6cR8oA6w5T2PwpTkIPc= Received: from 30.74.144.131(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WydAEKS_1770348810 cluster:ay36) by smtp.aliyun-inc.com; Fri, 06 Feb 2026 11:33:31 +0800 Message-ID: <3d0f189b-faab-4452-b9cc-8f4e7a15025f@linux.alibaba.com> Date: Fri, 6 Feb 2026 11:33:30 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [stable-6.6.y] mm: khugepaged refuses to freeze To: Sergey Senozhatsky , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Zi Yan Cc: "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: > > 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 > > ... > > 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);