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@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon,  6 Jul 2026 08:12:18 +0000 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.
>
> 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@xxxxxxxxxx