Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing
From: Richard Chang
Date: Tue Jul 07 2026 - 04:00:59 EST
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@xxxxxxxxxx> wrote:
>
> On Mon, Jul 6, 2026 at 4:12 PM Richard Chang <richardycc@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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