[PATCH] mm: vmscan: abort proactive reclaim early when freezing

[PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
signals in its outer loop in user_proactive_reclaim(). However, the inner
reclaim loops—scanning cgroups in shrink_many() and evicting folios in
try_to_shrink_lruvec() can run for a long time before returning to the
outer loop, especially on systems with many cgroups or large memory sizes.

This latency in responding to signals can block the freezer (both cgroup
freezer and system suspend), leading to freezer timeouts. This issue was
specifically observed on Android when attempting to freeze background
cgroups while proactive reclaim was active.

Add a signal_pending() check to should_abort_scan() for proactive reclaim
paths. Since should_abort_scan() is called within the inner scanning and
eviction loops, this allows proactive reclaim to abort early and return to
the outer loop, ensuring the task can enter the refrigerator in a timely
manner.

This check is limited to proactive reclaim (sc->proactive) to avoid
affecting reactive reclaim paths, and wrapped in unlikely() as it is a
slow path.

Signed-off-by: Richard Chang <richardycc@google.com>
---
 mm/vmscan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..fb472e924fc7 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
 	int i;
 	enum zone_watermarks mark;
 
+	if (unlikely(sc->proactive && signal_pending(current)))
+		return true;
+
 	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
 		return true;
 
-- 
2.55.0.rc2.803.g1fd1e6609c-goog

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Barry Song]

On Mon, Jul 6, 2026 at 4:12 PM Richard Chang <richardycc@google.com> wrote:
>
> Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> signals in its outer loop in user_proactive_reclaim(). However, the inner
> reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> try_to_shrink_lruvec() can run for a long time before returning to the
> outer loop, especially on systems with many cgroups or large memory sizes.
>
> This latency in responding to signals can block the freezer (both cgroup
> freezer and system suspend), leading to freezer timeouts. This issue was
> specifically observed on Android when attempting to freeze background
> cgroups while proactive reclaim was active.
>
> Add a signal_pending() check to should_abort_scan() for proactive reclaim
> paths. Since should_abort_scan() is called within the inner scanning and
> eviction loops, this allows proactive reclaim to abort early and return to
> the outer loop, ensuring the task can enter the refrigerator in a timely
> manner.
>
> This check is limited to proactive reclaim (sc->proactive) to avoid
> affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> slow path.
>
> Signed-off-by: Richard Chang <richardycc@google.com>
> ---
>  mm/vmscan.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 35c3bb15ae96..fb472e924fc7 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
>         int i;
>         enum zone_watermarks mark;
>
> +       if (unlikely(sc->proactive && signal_pending(current)))
> +               return true;
> +

Seems reasonable to me. I wonder if you have a script to
reproduce the issue. I'd like to test it.

Best Regards
Barry

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Andrew Morton]

On Mon,  6 Jul 2026 08:12:18 +0000 Richard Chang <richardycc@google.com> wrote:

> Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> signals in its outer loop in user_proactive_reclaim(). However, the inner
> reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> try_to_shrink_lruvec() can run for a long time before returning to the
> outer loop, especially on systems with many cgroups or large memory sizes.
> 
> This latency in responding to signals can block the freezer (both cgroup
> freezer and system suspend), leading to freezer timeouts. This issue was
> specifically observed on Android when attempting to freeze background
> cgroups while proactive reclaim was active.
> 
> Add a signal_pending() check to should_abort_scan() for proactive reclaim
> paths. Since should_abort_scan() is called within the inner scanning and
> eviction loops, this allows proactive reclaim to abort early and return to
> the outer loop, ensuring the task can enter the refrigerator in a timely
> manner.
> 
> This check is limited to proactive reclaim (sc->proactive) to avoid
> affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> slow path.

There are a number of ways of getting into proactive reclaim.  Have you
checked that all of them appropriately check and handle signal_pending()?

AI review thinks that classic LRU might need the same fix:
	https://sashiko.dev/#/patchset/20260706081218.3438762-1-richardycc@google.com

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Yosry Ahmed]

On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang wrote:
> Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> signals in its outer loop in user_proactive_reclaim(). However, the inner
> reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> try_to_shrink_lruvec() can run for a long time before returning to the
> outer loop, especially on systems with many cgroups or large memory sizes.
> 
> This latency in responding to signals can block the freezer (both cgroup
> freezer and system suspend), leading to freezer timeouts. This issue was
> specifically observed on Android when attempting to freeze background
> cgroups while proactive reclaim was active.
> 
> Add a signal_pending() check to should_abort_scan() for proactive reclaim
> paths. Since should_abort_scan() is called within the inner scanning and
> eviction loops, this allows proactive reclaim to abort early and return to
> the outer loop, ensuring the task can enter the refrigerator in a timely
> manner.

Do we still need the check in the outer loop?

> 
> This check is limited to proactive reclaim (sc->proactive) to avoid
> affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> slow path.
> 
> Signed-off-by: Richard Chang <richardycc@google.com>
> ---
>  mm/vmscan.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 35c3bb15ae96..fb472e924fc7 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
>  	int i;
>  	enum zone_watermarks mark;
>  
> +	if (unlikely(sc->proactive && signal_pending(current)))
> +		return true;
> +
>  	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
>  		return true;
>  
> -- 
> 2.55.0.rc2.803.g1fd1e6609c-goog
> 
> 

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

Hi Barry,

I use the following commands to test. The CGROUP_PATH depends on the
platform settings.

echo 1000 > /sys/power/pm_freeze_timeout
echo freezer > /sys/power/pm_test
while true; do echo 1024M >
/sys/fs/cgroup/$CGROUP_PATH/memory.reclaim; sleep 1; done
echo mem > /sys/power/state

BR,
Richard

On Mon, Jul 6, 2026 at 8:54 PM Barry Song <baohua@kernel.org> wrote:
>
> On Mon, Jul 6, 2026 at 4:12 PM Richard Chang <richardycc@google.com> wrote:
> >
> > Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> > signals in its outer loop in user_proactive_reclaim(). However, the inner
> > reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> > try_to_shrink_lruvec() can run for a long time before returning to the
> > outer loop, especially on systems with many cgroups or large memory sizes.
> >
> > This latency in responding to signals can block the freezer (both cgroup
> > freezer and system suspend), leading to freezer timeouts. This issue was
> > specifically observed on Android when attempting to freeze background
> > cgroups while proactive reclaim was active.
> >
> > Add a signal_pending() check to should_abort_scan() for proactive reclaim
> > paths. Since should_abort_scan() is called within the inner scanning and
> > eviction loops, this allows proactive reclaim to abort early and return to
> > the outer loop, ensuring the task can enter the refrigerator in a timely
> > manner.
> >
> > This check is limited to proactive reclaim (sc->proactive) to avoid
> > affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> > slow path.
> >
> > Signed-off-by: Richard Chang <richardycc@google.com>
> > ---
> >  mm/vmscan.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 35c3bb15ae96..fb472e924fc7 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
> >         int i;
> >         enum zone_watermarks mark;
> >
> > +       if (unlikely(sc->proactive && signal_pending(current)))
> > +               return true;
> > +
>
> Seems reasonable to me. I wonder if you have a script to
> reproduce the issue. I'd like to test it.
>
> Best Regards
> Barry

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

Hi Yosry,

I believe we still need the outer loop check. Otherwise, we will waste
CPU cycles entering the inner loop only to bail out.

On Tue, Jul 7, 2026 at 10:20 AM Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang wrote:
> > Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> > signals in its outer loop in user_proactive_reclaim(). However, the inner
> > reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> > try_to_shrink_lruvec() can run for a long time before returning to the
> > outer loop, especially on systems with many cgroups or large memory sizes.
> >
> > This latency in responding to signals can block the freezer (both cgroup
> > freezer and system suspend), leading to freezer timeouts. This issue was
> > specifically observed on Android when attempting to freeze background
> > cgroups while proactive reclaim was active.
> >
> > Add a signal_pending() check to should_abort_scan() for proactive reclaim
> > paths. Since should_abort_scan() is called within the inner scanning and
> > eviction loops, this allows proactive reclaim to abort early and return to
> > the outer loop, ensuring the task can enter the refrigerator in a timely
> > manner.
>
> Do we still need the check in the outer loop?
>
> >
> > This check is limited to proactive reclaim (sc->proactive) to avoid
> > affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> > slow path.
> >
> > Signed-off-by: Richard Chang <richardycc@google.com>
> > ---
> >  mm/vmscan.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 35c3bb15ae96..fb472e924fc7 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
> >       int i;
> >       enum zone_watermarks mark;
> >
> > +     if (unlikely(sc->proactive && signal_pending(current)))
> > +             return true;
> > +
> >       if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
> >               return true;
> >
> > --
> > 2.55.0.rc2.803.g1fd1e6609c-goog
> >
> >

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

Hi Andrew,

I believe there are three ways to trigger proactive reclaim:
1. Cgroup Proactive Reclaim: memory_reclaim()  ->  user_proactive_reclaim()
2. Node Proactive Reclaim: reclaim_store()  ->  user_proactive_reclaim()
3. Debugfs lru_gen: lru_gen_seq_write() -> run_cmd()  ->  run_eviction()

Methods (1) and (2) are covered by this patch, while (3) already
includes a while (!signal_pending(current)) check in run_eviction().

Regarding the AI feedback on the Classic LRU path, that is a valid
point. Since we have only observed this issue with MGLRU, I suspect it
is because in Classic LRU, the scan target per iteration is strictly
bounded by get_scan_count(), which ensures it returns to the outer
loop (where signals are checked) much more frequently.

On Tue, Jul 7, 2026 at 7:38 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon,  6 Jul 2026 08:12:18 +0000 Richard Chang <richardycc@google.com> wrote:
>
> > Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> > signals in its outer loop in user_proactive_reclaim(). However, the inner
> > reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> > try_to_shrink_lruvec() can run for a long time before returning to the
> > outer loop, especially on systems with many cgroups or large memory sizes.
> >
> > This latency in responding to signals can block the freezer (both cgroup
> > freezer and system suspend), leading to freezer timeouts. This issue was
> > specifically observed on Android when attempting to freeze background
> > cgroups while proactive reclaim was active.
> >
> > Add a signal_pending() check to should_abort_scan() for proactive reclaim
> > paths. Since should_abort_scan() is called within the inner scanning and
> > eviction loops, this allows proactive reclaim to abort early and return to
> > the outer loop, ensuring the task can enter the refrigerator in a timely
> > manner.
> >
> > This check is limited to proactive reclaim (sc->proactive) to avoid
> > affecting reactive reclaim paths, and wrapped in unlikely() as it is a
> > slow path.
>
> There are a number of ways of getting into proactive reclaim.  Have you
> checked that all of them appropriately check and handle signal_pending()?
>
> AI review thinks that classic LRU might need the same fix:
>         https://sashiko.dev/#/patchset/20260706081218.3438762-1-richardycc@google.com

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Yosry Ahmed]

> On Tue, Jul 7, 2026 at 10:20 AM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang wrote:
> > > Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> > > signals in its outer loop in user_proactive_reclaim(). However, the inner
> > > reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> > > try_to_shrink_lruvec() can run for a long time before returning to the
> > > outer loop, especially on systems with many cgroups or large memory sizes.
> > >
> > > This latency in responding to signals can block the freezer (both cgroup
> > > freezer and system suspend), leading to freezer timeouts. This issue was
> > > specifically observed on Android when attempting to freeze background
> > > cgroups while proactive reclaim was active.
> > >
> > > Add a signal_pending() check to should_abort_scan() for proactive reclaim
> > > paths. Since should_abort_scan() is called within the inner scanning and
> > > eviction loops, this allows proactive reclaim to abort early and return to
> > > the outer loop, ensuring the task can enter the refrigerator in a timely
> > > manner.
> >
> > Do we still need the check in the outer loop?
>
> I believe we still need the outer loop check. Otherwise, we will waste
> CPU cycles entering the inner loop only to bail out.

(Moving your reply after the relevant text, please avoid top-posting:
https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying).

My question was whether or not it matters in practice, sure we'll
waste some cycles but I don't think it would ultimately matter. That
being said, seems like this change only covers MGLRU, so we still need
the outer check at least for classic LRU.

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Shakeel Butt]

On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang wrote:
> Proactive reclaim (via memory.reclaim or node reclaim) checks for pending
> signals in its outer loop in user_proactive_reclaim(). However, the inner
> reclaim loops—scanning cgroups in shrink_many() and evicting folios in
> try_to_shrink_lruvec() can run for a long time before returning to the
> outer loop, especially on systems with many cgroups or large memory sizes.
> 
> This latency in responding to signals can block the freezer (both cgroup
> freezer and system suspend), leading to freezer timeouts. This issue was
> specifically observed on Android when attempting to freeze background
> cgroups while proactive reclaim was active.
> 

Can you please explain how freezing operation was delayed due to proactive
reclaim? 

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

On Wed, Jul 8, 2026 at 3:48 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> Can you please explain how freezing operation was delayed due to proactive
> reclaim?
>
Hi Shakeel,

When system suspend is initiated, the Power Management (PM) freezer
attempts to freeze all user-space processes by calling
freeze_processes(), signaling user space processes to enter the
refrigerator. When a user-space task writes to memory.reclaim to
trigger proactive reclaim, it executes in kernel context and enters
the reclaim loop. Currently the task does not check  signal_pending()
within the inner loops, it cannot abort the reclaim pass early. It
continues reclaiming memory, ignoring the freeze request. The PM
freezer waits for all tasks to freeze. If the proactive reclaim task
remains in the inner loops longer than the freeze timeout, the freezer
times out, and suspend fails.

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Shakeel Butt]

On Wed, Jul 08, 2026 at 12:14:50PM +0800, Richard Chang wrote:
> On Wed, Jul 8, 2026 at 3:48 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > Can you please explain how freezing operation was delayed due to proactive
> > reclaim?
> >
> Hi Shakeel,
> 
> When system suspend is initiated, the Power Management (PM) freezer
> attempts to freeze all user-space processes by calling
> freeze_processes(), signaling user space processes to enter the
> refrigerator. When a user-space task writes to memory.reclaim to
> trigger proactive reclaim, it executes in kernel context and enters
> the reclaim loop. Currently the task does not check  signal_pending()
> within the inner loops, it cannot abort the reclaim pass early. It
> continues reclaiming memory, ignoring the freeze request. The PM
> freezer waits for all tasks to freeze. If the proactive reclaim task
> remains in the inner loops longer than the freeze timeout, the freezer
> times out, and suspend fails.

What's so special about proactive reclaim? Why the same situation can not happen
for global or memcg reclaim?

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Richard Chang]

On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> What's so special about proactive reclaim? Why the same situation can not happen
> for global or memcg reclaim?
>

The target batch size of the global/memcg reclaim is typically very
small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
yield or check signals between attempts.
Furthermore, kswapd is a kernel thread designed to be freezable, it
explicitly checks kthread_freezable_should_stop() in the main loop.
In contrast, the target batch size in proactive reclaim is
user-defined and can be extremely large. Without signal checks in the
inner loops, the task may continue scanning and evicting pages for
seconds at a time.

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Shakeel Butt]

On Wed, Jul 08, 2026 at 03:24:15PM +0800, Richard Chang wrote:
> On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > What's so special about proactive reclaim? Why the same situation can not happen
> > for global or memcg reclaim?
> >
> 
> The target batch size of the global/memcg reclaim is typically very
> small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
> yield or check signals between attempts.
> Furthermore, kswapd is a kernel thread designed to be freezable, it
> explicitly checks kthread_freezable_should_stop() in the main loop.
> In contrast, the target batch size in proactive reclaim is
> user-defined and can be extremely large. Without signal checks in the
> inner loops, the task may continue scanning and evicting pages for
> seconds at a time.

Why can't the proactive reclaim use the same batch size as memcg and global
reclaim?

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[T.J. Mercier]

On Wed, Jul 8, 2026 at 8:48 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> On Wed, Jul 08, 2026 at 03:24:15PM +0800, Richard Chang wrote:
> > On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> > >
> > > What's so special about proactive reclaim? Why the same situation can not happen
> > > for global or memcg reclaim?
> > >
> >
> > The target batch size of the global/memcg reclaim is typically very
> > small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
> > yield or check signals between attempts.
> > Furthermore, kswapd is a kernel thread designed to be freezable, it
> > explicitly checks kthread_freezable_should_stop() in the main loop.
> > In contrast, the target batch size in proactive reclaim is
> > user-defined and can be extremely large. Without signal checks in the
> > inner loops, the task may continue scanning and evicting pages for
> > seconds at a time.
>
> Why can't the proactive reclaim use the same batch size as memcg and global
> reclaim?

Because it is very slow:
https://lore.kernel.org/all/20240202233855.1236422-1-tjmercier@google.com/

Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing

[Shakeel Butt]

On Wed, Jul 08, 2026 at 09:03:17AM -0700, T.J. Mercier wrote:
> On Wed, Jul 8, 2026 at 8:48 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > On Wed, Jul 08, 2026 at 03:24:15PM +0800, Richard Chang wrote:
> > > On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> > > >
> > > > What's so special about proactive reclaim? Why the same situation can not happen
> > > > for global or memcg reclaim?
> > > >
> > >
> > > The target batch size of the global/memcg reclaim is typically very
> > > small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
> > > yield or check signals between attempts.
> > > Furthermore, kswapd is a kernel thread designed to be freezable, it
> > > explicitly checks kthread_freezable_should_stop() in the main loop.
> > > In contrast, the target batch size in proactive reclaim is
> > > user-defined and can be extremely large. Without signal checks in the
> > > inner loops, the task may continue scanning and evicting pages for
> > > seconds at a time.
> >
> > Why can't the proactive reclaim use the same batch size as memcg and global
> > reclaim?
> 
> Because it is very slow:
> https://lore.kernel.org/all/20240202233855.1236422-1-tjmercier@google.com/

Yes, we should fix reclaim and preferrably have single solution for all types of
reclaim. Though that is orthogonal and out of scope for this patch.

The reason behind my questioning is that the commit message should have all of
this information from the start instead of requiring readers to extract all of
this.

[PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Richard Chang]

Proactive reclaim (triggered via memory.reclaim or node sysfs)
checks for pending signals in its outer loop in
user_proactive_reclaim(). However, the inner reclaim
loops—specifically scanning cgroups in shrink_many() and
evicting/aging folios in try_to_shrink_lruvec()—can run for a long
time before returning to the outer loop, especially on systems with
many cgroups or large memory sizes.

During system suspend, the PM freezer attempts to freeze all the tasks
by sending signals. Because the inner loops do not check for pending
signals, the proactive reclaim task can remain stuck in kernel space
for seconds, failing to enter the refrigerator in a timely manner. This
leads to suspend failures due to freeze timeouts, a behavior observed
on Android devices.

This latency issue is specific to proactive reclaim because of its
large, user-defined reclaim targets (could be gigabytes). Since commit
287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"),
proactive reclaim uses larger decaying batch sizes (starting at 1/4
of the remaining target) to maintain throughput. This keeps the task
in the reclaim loop with a large target for a single syscall
invocation. In contrast, reactive reclaim (global/memcg) has small
targets (SWAP_CLUSTER_MAX, typically 32 pages), allowing to yield or
check signals between attempts quickly.

To fix this, add a signal_pending() check to should_abort_scan() for
proactive reclaim paths. Since should_abort_scan() is called within
the inner scanning and eviction loops, this allows proactive reclaim to
abort early and return to the outer loop, ensuring the task can enter
the refrigerator and allow suspend to proceed.

The check is limited to proactive reclaim (sc->proactive) to avoid
affecting reactive reclaim paths, and wrapped in unlikely() as it
is a slow path.

Signed-off-by: Richard Chang <richardycc@google.com>
---
v2: Update the commit message

 mm/vmscan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..fb472e924fc7 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
 	int i;
 	enum zone_watermarks mark;
 
+	if (unlikely(sc->proactive && signal_pending(current)))
+		return true;
+
 	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
 		return true;
 
-- 
2.55.0.795.g602f6c329a-goog

Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Michal Hocko]

On Thu 09-07-26 07:22:31, Richard Chang wrote:
> Proactive reclaim (triggered via memory.reclaim or node sysfs)
> checks for pending signals in its outer loop in
> user_proactive_reclaim(). However, the inner reclaim
> loops—specifically scanning cgroups in shrink_many() and
> evicting/aging folios in try_to_shrink_lruvec()—can run for a long
> time before returning to the outer loop, especially on systems with
> many cgroups or large memory sizes.
> 
> During system suspend, the PM freezer attempts to freeze all the tasks
> by sending signals. Because the inner loops do not check for pending
> signals, the proactive reclaim task can remain stuck in kernel space
> for seconds, failing to enter the refrigerator in a timely manner. This
> leads to suspend failures due to freeze timeouts, a behavior observed
> on Android devices.
> 
> This latency issue is specific to proactive reclaim because of its
> large, user-defined reclaim targets (could be gigabytes). Since commit
> 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"),
> proactive reclaim uses larger decaying batch sizes (starting at 1/4
> of the remaining target) to maintain throughput. This keeps the task
> in the reclaim loop with a large target for a single syscall
> invocation. In contrast, reactive reclaim (global/memcg) has small
> targets (SWAP_CLUSTER_MAX, typically 32 pages), allowing to yield or
> check signals between attempts quickly.
> 
> To fix this, add a signal_pending() check to should_abort_scan() for
> proactive reclaim paths. Since should_abort_scan() is called within
> the inner scanning and eviction loops, this allows proactive reclaim to
> abort early and return to the outer loop, ensuring the task can enter
> the refrigerator and allow suspend to proceed.
> 
> The check is limited to proactive reclaim (sc->proactive) to avoid
> affecting reactive reclaim paths, and wrapped in unlikely() as it
> is a slow path.

The changelog doesn't explain whether this is MGRLU specific problem as
the fix is MGRLU specific AFAICS.

Also do I get it right that freezing a task while doing the pro-active
reclaim will force EINTR early return even if no real signal was
delivered to the task?

> Signed-off-by: Richard Chang <richardycc@google.com>
> ---
> v2: Update the commit message
> 
>  mm/vmscan.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 35c3bb15ae96..fb472e924fc7 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
>  	int i;
>  	enum zone_watermarks mark;
>  
> +	if (unlikely(sc->proactive && signal_pending(current)))
> +		return true;
> +
>  	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
>  		return true;
>  
> -- 
> 2.55.0.795.g602f6c329a-goog

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Richard Chang]

Hi Michal,

On Thu, Jul 9, 2026 at 8:06 PM Michal Hocko <mhocko@suse.com> wrote:
>
> The changelog doesn't explain whether this is MGRLU specific problem as
> the fix is MGRLU specific AFAICS.
>
I will prepare the v3 changelog update. Thanks.

> Also do I get it right that freezing a task while doing the pro-active
> reclaim will force EINTR early return even if no real signal was
> delivered to the task?
>
Yes, that is correct.
The PM freezer ( freeze_task() ) calls fake_signal_wake_up(), which
sets TIF_SIGPENDING on the target task.
Returning -EINTR when checking by signal_pending(current) is already
the existing behavior of user_proactive_reclaim().
This patch does not change the behavior, it just allows the task to
exit the inner loop quickly.

Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Michal Hocko]

On Fri 10-07-26 11:29:25, Richard Chang wrote:
> Hi Michal,
> 
> On Thu, Jul 9, 2026 at 8:06 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > The changelog doesn't explain whether this is MGRLU specific problem as
> > the fix is MGRLU specific AFAICS.
> >
> I will prepare the v3 changelog update. Thanks.
> 
> > Also do I get it right that freezing a task while doing the pro-active
> > reclaim will force EINTR early return even if no real signal was
> > delivered to the task?
> >
> Yes, that is correct.
> The PM freezer ( freeze_task() ) calls fake_signal_wake_up(), which
> sets TIF_SIGPENDING on the target task.
> Returning -EINTR when checking by signal_pending(current) is already
> the existing behavior of user_proactive_reclaim().
> This patch does not change the behavior, it just allows the task to
> exit the inner loop quickly.

I believe this is a wrong behavior. Freezer should be invisible from the
userspace POV. Your patch makes the pre-existing problem much more
visible. I believe we need a slightly different approach. Should we
try_to_freeze in well defined places in the reclaim and turn 
user_proactive_reclaim to fatal_signal_pending?

-- 
Michal Hocko
SUSE Labs