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

[Yosry Ahmed <yosry@kernel.org>]

> On Tue, Jul 7, 2026 at 10:20 AM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang 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.
> >
> > Do we still need the check in the outer loop?
>
> I believe we still need the outer loop check. Otherwise, we will waste
> CPU cycles entering the inner loop only to bail out.

(Moving your reply after the relevant text, please avoid top-posting:
https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying).

My question was whether or not it matters in practice, sure we'll
waste some cycles but I don't think it would ultimately matter. That
being said, seems like this change only covers MGLRU, so we still need
the outer check at least for classic LRU.