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

[PATCH v3] 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 tasks by
sending fake signals (setting TIF_SIGPENDING). 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 inner reclaim loop for extended periods. In contrast, reactive
reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
32 pages), allowing it to return to the outer loop and check signals
frequently.

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 in user_proactive_reclaim().

Additionally, return -ERESTARTSYS instead of -EINTR in
user_proactive_reclaim(). When interrupted by system suspend, returning
-ERESTARTSYS allows the task to enter the refrigerator and automatically
restart the syscall upon resume, making the freezer transparent to
userspace. If interrupted by an unhandled real signal (e.g. SIGINT),
the kernel signal layer automatically converts -ERESTARTSYS to -EINTR.

This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
targets per iteration are strictly bounded by get_scan_count(), which
ensures it returns to the outer loop more frequently.

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

Suggested-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Richard Chang <richardycc@google.com>
---
v2: Update the commit message
v3: Return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim

 mm/vmscan.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..0fda811fcb05 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;
 
@@ -7909,8 +7912,14 @@ int user_proactive_reclaim(char *buf,
 		unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
 		unsigned long reclaimed;
 
+		/*
+		 * Return -ERESTARTSYS to allow the freezer to interrupt the
+		 * task. The syscall will be transparently restarted upon
+		 * resume. Real signals (e.g. SIGINT) will be automatically
+		 * converted to -EINTR by the signal layer.
+		 */
 		if (signal_pending(current))
-			return -EINTR;
+			return -ERESTARTSYS;
 
 		/*
 		 * This is the final attempt, drain percpu lru caches in the
-- 
2.55.0.229.g6434b31f56-goog

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

[Oleg Nesterov]

On 07/17, Richard Chang wrote:
>
> v3: Return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim

Yes, this change LGTM, but ...

> +		/*
> +		 * Return -ERESTARTSYS to allow the freezer to interrupt the
> +		 * task. The syscall will be transparently restarted upon
> +		 * resume. Real signals (e.g. SIGINT) will be automatically
> +		 * converted to -EINTR by the signal layer.
> +		 */

... the comment looks a bit misleading...

So, if the signal is "real" and has a handler, handle_signal() does

		case -ERESTARTSYS:
			if (!(ksig->ka.sa.sa_flags & SA_RESTART)) {
				regs->ax = -EINTR;
				break;
			}
			fallthrough;
		case -ERESTARTNOINTR:
			regs->ax = regs->orig_ax;
			regs->ip -= 2;
			break;

If SA_RESTART is set, the syscall will be restarted after return from
signal handler.

Oleg.

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

[Richard Chang]

Hi Oleg,

You are right, and this is a great catch.
I am updating v4 to accurately reflect the `SA_RESTART` semantics.
Thanks!

[PATCH v4] 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 tasks by
sending fake signals (setting TIF_SIGPENDING). 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 inner reclaim loop for extended periods. In contrast, reactive
reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
32 pages), allowing it to return to the outer loop and check signals
frequently.

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 in user_proactive_reclaim().

Additionally, return -ERESTARTSYS instead of -EINTR in
user_proactive_reclaim(). When interrupted by system suspend, returning
-ERESTARTSYS allows the task to enter the refrigerator and automatically
restart the syscall upon resume, making the freezer transparent to
userspace. For real signals, the signal layer will either restart the
syscall (if SA_RESTART is set) or return -EINTR to userspace.

This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
targets per iteration are strictly bounded by get_scan_count(), which
ensures it returns to the outer loop more frequently.

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

Suggested-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Richard Chang <richardycc@google.com>
---
v2: Update the commit message
v3: Return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim
v4: Clarify -ERESTARTSYS vs SA_RESTART behavior

 mm/vmscan.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 35c3bb15ae96..5aa4becacb7f 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;
 
@@ -7909,8 +7912,15 @@ int user_proactive_reclaim(char *buf,
 		unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
 		unsigned long reclaimed;
 
+		/*
+		 * Return -ERESTARTSYS to allow the freezer to interrupt the
+		 * task. The syscall will be transparently restarted upon
+		 * resume. For real signals, it either restarts the syscall
+		 * (if SA_RESTART is set) or is converted to -EINTR by the
+		 * signal layer.
+		 */
 		if (signal_pending(current))
-			return -EINTR;
+			return -ERESTARTSYS;
 
 		/*
 		 * This is the final attempt, drain percpu lru caches in the
-- 
2.55.0.229.g6434b31f56-goog

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

[Andrew Morton]

On Mon, 20 Jul 2026 04:41:03 +0000 Richard Chang <richardycc@google.com> 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 tasks by
> sending fake signals (setting TIF_SIGPENDING). 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 inner reclaim loop for extended periods. In contrast, reactive
> reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
> 32 pages), allowing it to return to the outer loop and check signals
> frequently.

So 287d5fedb377 led to suspend failures on MGLRU-using kernels.

That's a regression which justifies a Fixes: and a cc:stable, don't
people agree?

AI review asked a couple of serious-sounding questions:
	https://sashiko.dev/#/patchset/20260720044103.905191-1-richardycc@google.com

> 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 in user_proactive_reclaim().
> 
> Additionally, return -ERESTARTSYS instead of -EINTR in
> user_proactive_reclaim(). When interrupted by system suspend, returning
> -ERESTARTSYS allows the task to enter the refrigerator and automatically
> restart the syscall upon resume, making the freezer transparent to
> userspace. For real signals, the signal layer will either restart the
> syscall (if SA_RESTART is set) or return -EINTR to userspace.
> 
> This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
> targets per iteration are strictly bounded by get_scan_count(), which
> ensures it returns to the outer loop more frequently.
> 
> The check in should_abort_scan() is limited to proactive reclaim
> (sc->proactive) to avoid inadvertently affecting reactive reclaim paths,
> and is wrapped in unlikely() as it is a slow path.
> 

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

[Richard Chang]

Hi Andrew,
Thanks for pointing that out.

On Mon, Jul 20, 2026 at 1:23 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> So 287d5fedb377 led to suspend failures on MGLRU-using kernels.
>
> That's a regression which justifies a Fixes: and a cc:stable, don't
> people agree?
>
> AI review asked a couple of serious-sounding questions:
>         https://sashiko.dev/#/patchset/20260720044103.905191-1-richardycc@google.com
>

Hi Michal and Oleg,

The -ERESTARTSYS concern raised during the AI review seems reasonable:
1. Over-Reclaim: If a task has already reclaimed 900MB of a 1GB
request before being interrupted by a suspend, an -ERESTARTSYS would
attempt to reclaim another 1GB when resuming, resulting in up to 1.9GB
of over-reclaim.
2. Incompatibility Node-Reclaim: Since reclaim_store() unconditionally
converts any non-zero return value from user_proactive_reclaim() into
-EAGAIN, it will not restart the syscall for node reclaim.
Given these constraints, do you think we should keep -EINTR in
user_proactive_reclaim()?

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

[Michal Hocko]

On Mon 20-07-26 04:41:03, 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 tasks by
> sending fake signals (setting TIF_SIGPENDING). 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 inner reclaim loop for extended periods. In contrast, reactive
> reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
> 32 pages), allowing it to return to the outer loop and check signals
> frequently.
> 
> 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 in user_proactive_reclaim().
> 
> Additionally, return -ERESTARTSYS instead of -EINTR in
> user_proactive_reclaim(). When interrupted by system suspend, returning
> -ERESTARTSYS allows the task to enter the refrigerator and automatically
> restart the syscall upon resume, making the freezer transparent to
> userspace. For real signals, the signal layer will either restart the
> syscall (if SA_RESTART is set) or return -EINTR to userspace.
> 
> This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
> targets per iteration are strictly bounded by get_scan_count(), which
> ensures it returns to the outer loop more frequently.
> 
> The check in should_abort_scan() is limited to proactive reclaim
> (sc->proactive) to avoid inadvertently affecting reactive reclaim paths,
> and is wrapped in unlikely() as it is a slow path.
> 
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Suggested-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Richard Chang <richardycc@google.com>

Acked-by: Michal Hocko <mhocko@suse.com>
Thanks

> ---
> v2: Update the commit message
> v3: Return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim
> v4: Clarify -ERESTARTSYS vs SA_RESTART behavior
> 
>  mm/vmscan.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 35c3bb15ae96..5aa4becacb7f 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;
>  
> @@ -7909,8 +7912,15 @@ int user_proactive_reclaim(char *buf,
>  		unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4;
>  		unsigned long reclaimed;
>  
> +		/*
> +		 * Return -ERESTARTSYS to allow the freezer to interrupt the
> +		 * task. The syscall will be transparently restarted upon
> +		 * resume. For real signals, it either restarts the syscall
> +		 * (if SA_RESTART is set) or is converted to -EINTR by the
> +		 * signal layer.
> +		 */
>  		if (signal_pending(current))
> -			return -EINTR;
> +			return -ERESTARTSYS;
>  
>  		/*
>  		 * This is the final attempt, drain percpu lru caches in the
> -- 
> 2.55.0.229.g6434b31f56-goog

-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

On Sun 19-07-26 22:23:06, Andrew Morton wrote:
> On Mon, 20 Jul 2026 04:41:03 +0000 Richard Chang <richardycc@google.com> 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 tasks by
> > sending fake signals (setting TIF_SIGPENDING). 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 inner reclaim loop for extended periods. In contrast, reactive
> > reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically
> > 32 pages), allowing it to return to the outer loop and check signals
> > frequently.
> 
> So 287d5fedb377 led to suspend failures on MGLRU-using kernels.
> 
> That's a regression which justifies a Fixes: and a cc:stable, don't
> people agree?

I believe this should have both Fixes: 287d5fedb377 and 94968384dde1.
-- 
Michal Hocko
SUSE Labs