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

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

[Sergey Senozhatsky]

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.

Co-developed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---

v1->v2: Actually pass "cc" to hpage_collapse_test_exit_or_disable()

 mm/khugepaged.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index eff9e3061925..d32a5ad27097 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -392,10 +392,18 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
 	return atomic_read(&mm->mm_users) == 0;
 }
 
-static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
+static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
+						struct collapse_control *cc)
 {
+	bool was_frozen = false;
+
+	if (cc->is_khugepaged &&
+	    unlikely(kthread_freezable_should_stop(&was_frozen)))
+		return 1;
+
 	return hpage_collapse_test_exit(mm) ||
-		mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm);
+		mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm) ||
+		was_frozen;
 }
 
 static bool hugepage_pmd_enabled(void)
@@ -895,7 +903,7 @@ static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned l
 	enum tva_type type = cc->is_khugepaged ? TVA_KHUGEPAGED :
 				 TVA_FORCED_COLLAPSE;
 
-	if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
+	if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
 		return SCAN_ANY_PROCESS;
 
 	*vmap = vma = find_vma(mm, address);
@@ -2420,7 +2428,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
 		goto breakouterloop_mmap_lock;
 
 	progress++;
-	if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
+	if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
 		goto breakouterloop;
 
 	vma_iter_init(&vmi, mm, khugepaged_scan.address);
@@ -2428,7 +2436,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
 		unsigned long hstart, hend;
 
 		cond_resched();
-		if (unlikely(hpage_collapse_test_exit_or_disable(mm))) {
+		if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc))) {
 			progress++;
 			break;
 		}
@@ -2450,7 +2458,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
 			bool mmap_locked = true;
 
 			cond_resched();
-			if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
+			if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
 				goto breakouterloop;
 
 			VM_BUG_ON(khugepaged_scan.address < hstart ||
@@ -2468,7 +2476,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
 				fput(file);
 				if (*result == SCAN_PTE_MAPPED_HUGEPAGE) {
 					mmap_read_lock(mm);
-					if (hpage_collapse_test_exit_or_disable(mm))
+					if (hpage_collapse_test_exit_or_disable(mm, cc))
 						goto breakouterloop;
 					*result = try_collapse_pte_mapped_thp(mm,
 						khugepaged_scan.address, false);
-- 
2.53.0.239.g8d8fc8a987-goog

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

[Nico Pache]

On Tue, Feb 10, 2026 at 8:15 PM Sergey Senozhatsky
<senozhatsky@chromium.org> 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.
>
> Co-developed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>

Hi Sergey!

Thank you for reporting this and taking the time to investigate a fix.

Here are some simple review points then I'll comment on the code below.

- We usually send "To:" the mailing lists and "CC:" to all other people.
- Your subject contains "PATCHv2" there should be a space there
- It would be worth noting the "HOW" in the commit message

> ---
>
> v1->v2: Actually pass "cc" to hpage_collapse_test_exit_or_disable()
>
>  mm/khugepaged.c | 22 +++++++++++++++-------
>  1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index eff9e3061925..d32a5ad27097 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -392,10 +392,18 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
>         return atomic_read(&mm->mm_users) == 0;
>  }
>
> -static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
> +static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> +                                               struct collapse_control *cc)
>  {
> +       bool was_frozen = false;
> +
> +       if (cc->is_khugepaged &&
> +           unlikely(kthread_freezable_should_stop(&was_frozen)))
> +               return 1;
> +
>         return hpage_collapse_test_exit(mm) ||
> -               mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm);
> +               mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm) ||
> +               was_frozen;

I dont really understand the freezer code, and there are few examples
of this. But given how other callers do it, this seems correct.

>  }
>
>  static bool hugepage_pmd_enabled(void)
> @@ -895,7 +903,7 @@ static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned l
>         enum tva_type type = cc->is_khugepaged ? TVA_KHUGEPAGED :
>                                  TVA_FORCED_COLLAPSE;
>
> -       if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
> +       if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
>                 return SCAN_ANY_PROCESS;
>
>         *vmap = vma = find_vma(mm, address);
> @@ -2420,7 +2428,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
>                 goto breakouterloop_mmap_lock;
>
>         progress++;
> -       if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
> +       if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
>                 goto breakouterloop;
>
>         vma_iter_init(&vmi, mm, khugepaged_scan.address);
> @@ -2428,7 +2436,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
>                 unsigned long hstart, hend;
>
>                 cond_resched();
> -               if (unlikely(hpage_collapse_test_exit_or_disable(mm))) {
> +               if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc))) {
>                         progress++;
>                         break;
>                 }
> @@ -2450,7 +2458,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
>                         bool mmap_locked = true;
>
>                         cond_resched();
> -                       if (unlikely(hpage_collapse_test_exit_or_disable(mm)))
> +                       if (unlikely(hpage_collapse_test_exit_or_disable(mm, cc)))
>                                 goto breakouterloop;
>
>                         VM_BUG_ON(khugepaged_scan.address < hstart ||
> @@ -2468,7 +2476,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, enum scan_result
>                                 fput(file);
>                                 if (*result == SCAN_PTE_MAPPED_HUGEPAGE) {
>                                         mmap_read_lock(mm);
> -                                       if (hpage_collapse_test_exit_or_disable(mm))
> +                                       if (hpage_collapse_test_exit_or_disable(mm, cc))
>                                                 goto breakouterloop;
>                                         *result = try_collapse_pte_mapped_thp(mm,
>                                                 khugepaged_scan.address, false);
> --
> 2.53.0.239.g8d8fc8a987-goog
>

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

[David Hildenbrand (Arm)]

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?

> Co-developed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> 
> v1->v2: Actually pass "cc" to hpage_collapse_test_exit_or_disable()
> 
>   mm/khugepaged.c | 22 +++++++++++++++-------
>   1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index eff9e3061925..d32a5ad27097 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -392,10 +392,18 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
>   	return atomic_read(&mm->mm_users) == 0;
>   }
>   
> -static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
> +static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> +						struct collapse_control *cc)

Two-tab indent, please.

>   {
> +	bool was_frozen = false;
> +
> +	if (cc->is_khugepaged &&
> +	    unlikely(kthread_freezable_should_stop(&was_frozen)))
> +		return 1;

I'm trying to understand why kthread_freezable_should_stop() is so 
confusing.

It has this !kthread_should_stop() logic in there, which, IIUC, is not 
really required for the issue here.

But it doesn't hurt to check here whether the kthread is getting shut down.

Relevant for the fix is for us to quit when was_frozen is set, so we can 
end up in khugepaged_wait_work()->wait_event_freezable_timeout().


So using kthread_freezable_should_stop() is fine.


> +
>   	return hpage_collapse_test_exit(mm) ||
> -		mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm);
> +		mm_flags_test(MMF_DISABLE_THP_COMPLETELY, mm) ||
> +		was_frozen;
>   }


Do we also have to enlighten the kthread_should_stop() check in 
khugepaged_do_scan() to check kthread_freezable_should_stop() instead?

-- 
Cheers,

David

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

[Sergey Senozhatsky]

On (26/02/11 10:50), David Hildenbrand (Arm) wrote:
> > 
> > v1->v2: Actually pass "cc" to hpage_collapse_test_exit_or_disable()
> > 
> >   mm/khugepaged.c | 22 +++++++++++++++-------
> >   1 file changed, 15 insertions(+), 7 deletions(-)
> > 
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index eff9e3061925..d32a5ad27097 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -392,10 +392,18 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
> >   	return atomic_read(&mm->mm_users) == 0;
> >   }
> > -static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
> > +static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> > +						struct collapse_control *cc)
> 
> Two-tab indent, please.

I initially had it like

@@ -393,7 +393,7 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
 }
 
 static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
-						struct collapse_control *cc)
+						      struct collapse_control *cc)
 {

but wasn't sure about the 80-col breakage.  Is that what you meant by
two-tab indent?

[..]
> Do we also have to enlighten the kthread_should_stop() check in
> khugepaged_do_scan() to check kthread_freezable_should_stop() instead?

Most likely yes, will do in v3.

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

[Sergey Senozhatsky]

On (26/02/10 23:15), Nico Pache wrote:
> - We usually send "To:" the mailing lists and "CC:" to all other people.
> - Your subject contains "PATCHv2" there should be a space there
> - It would be worth noting the "HOW" in the commit message

Ack.

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

[Sergey Senozhatsky]

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.

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

[David Hildenbrand (Arm)]

On 2/12/26 02:50, Sergey Senozhatsky wrote:
> On (26/02/11 10:50), David Hildenbrand (Arm) wrote:
>>>
>>> v1->v2: Actually pass "cc" to hpage_collapse_test_exit_or_disable()
>>>
>>>    mm/khugepaged.c | 22 +++++++++++++++-------
>>>    1 file changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index eff9e3061925..d32a5ad27097 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -392,10 +392,18 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
>>>    	return atomic_read(&mm->mm_users) == 0;
>>>    }
>>> -static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
>>> +static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
>>> +						struct collapse_control *cc)
>>
>> Two-tab indent, please.
> 
> I initially had it like
> 
> @@ -393,7 +393,7 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
>   }
>   
>   static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> -						struct collapse_control *cc)
> +						      struct collapse_control *cc)
>   {
> 
> but wasn't sure about the 80-col breakage.  Is that what you meant by
> two-tab indent?

In MM we prefer

static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
		struct collapse_control *cc)

		^ two tabs

Because it's the least ugly when you have long functions + many parameters, and
renaming the function/changing return type will often not require touching each and
every other parameter line.

-- 
Cheers,

David

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

[Sergey Senozhatsky]

On (26/02/12 09:30), David Hildenbrand (Arm) wrote:
[..]
> > > > -static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm)
> > > > +static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> > > > +						struct collapse_control *cc)
> > > 
> > > Two-tab indent, please.
> > 
> > I initially had it like
> > 
> > @@ -393,7 +393,7 @@ static inline int hpage_collapse_test_exit(struct mm_struct *mm)
> >   }
> >   static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> > -						struct collapse_control *cc)
> > +						      struct collapse_control *cc)
> >   {
> > 
> > but wasn't sure about the 80-col breakage.  Is that what you meant by
> > two-tab indent?
> 
> In MM we prefer
> 
> static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm,
> 		struct collapse_control *cc)
> 
> 		^ two tabs

Ack.

I certainly see "(" alignment in that file (e.g. khugepaged_scan_mm_slot(),
__collapse_huge_page_copy_failed(), etc.) so I thought that maybe that was
what you meant.

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

[David Hildenbrand (Arm)]

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

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

[Sergey Senozhatsky]

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"?

> 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?

> 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.

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

[David Hildenbrand (Arm)]

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)

-- 
Cheers,

David

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

[Sergey Senozhatsky]

On (26/02/12 10:10), David Hildenbrand (Arm) wrote:
> > 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.

6.6 stable doesn't have b39ca208403c8f2 - khugepaged_do_scan() checks
both kthread_should_stop() and try_to_freeze().

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

[Lance Yang]

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

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

[David Hildenbrand (Arm)]

On 2/14/26 07:35, Lance Yang wrote:
> 
> 
> On 2026/2/12 17:10, David Hildenbrand (Arm) wrote:
>> On 2/12/26 10:05, Sergey Senozhatsky wrote:
>>> [..]
>>>
>>> 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.
>>
>>>
>>>
>>> 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.
>>
>>>
>>>
>>> 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.

But 20 seconds to swap in 4096 pages (16 MiB)?

Okay, on arm64 with 64k it would be a lot more (8 * 512 MiB == 4 GiB).
With With 16k we're at 8 * 32MiB = 256 MiB.

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

I'd only do that if we have evidence that it's actually helpful.

@Sergey, with which base page size are you running (4k vs. 16k vs 64k)? 
I assume your report is on aarch64, correct?

-- 
Cheers,

David

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

[Sergey Senozhatsky]

On (26/02/16 10:24), David Hildenbrand (Arm) wrote:
> > Maybe we also need check points inside these loops to bail out early?
> 
> I'd only do that if we have evidence that it's actually helpful.
> 
> @Sergey, with which base page size are you running (4k vs. 16k vs 64k)? I
> assume your report is on aarch64, correct?

I had reports from a 2 CPU Intel n50 device, with 4096 PAGE_SIZE.
I'm trying to repro on that device now (by running suspend/resume
in a loop), but not much luck so far.

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

[Sergey Senozhatsky]

On (26/02/16 18:50), Sergey Senozhatsky wrote:
> On (26/02/16 10:24), David Hildenbrand (Arm) wrote:
> > > Maybe we also need check points inside these loops to bail out early?
> > 
> > I'd only do that if we have evidence that it's actually helpful.
> > 
> > @Sergey, with which base page size are you running (4k vs. 16k vs 64k)? I
> > assume your report is on aarch64, correct?
> 
> I had reports from a 2 CPU Intel n50 device, with 4096 PAGE_SIZE.
> I'm trying to repro on that device now (by running suspend/resume
		      ^^^ on a similar device, not exactly the same.
So I guess I wouldn't rule out the possibility of a h/w issue.