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@xxxxxxxxxx> 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