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

[Barry Song]

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