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

[Andrew Morton <akpm@linux-foundation.org>]

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