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