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

[T.J. Mercier]

On Wed, Jul 8, 2026 at 8:48 AM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>
> 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?

Because it is very slow:
https://lore.kernel.org/all/20240202233855.1236422-1-tjmercier@xxxxxxxxxx/