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

[Shakeel Butt]

On Wed, Jul 08, 2026 at 03:24:15PM +0800, Richard Chang wrote:
> On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
> >
> > What's so special about proactive reclaim? Why the same situation can not happen
> > for global or memcg reclaim?
> >
> 
> The target batch size of the global/memcg reclaim is typically very
> small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
> yield or check signals between attempts.
> Furthermore, kswapd is a kernel thread designed to be freezable, it
> explicitly checks kthread_freezable_should_stop() in the main loop.
> In contrast, the target batch size in proactive reclaim is
> user-defined and can be extremely large. Without signal checks in the
> inner loops, the task may continue scanning and evicting pages for
> seconds at a time.

Why can't the proactive reclaim use the same batch size as memcg and global
reclaim?