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

[Richard Chang <richardycc@google.com>]

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