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

[Shakeel Butt]

On Wed, Jul 08, 2026 at 09:03:17AM -0700, T.J. Mercier wrote:
> 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/

Yes, we should fix reclaim and preferrably have single solution for all types of
reclaim. Though that is orthogonal and out of scope for this patch.

The reason behind my questioning is that the commit message should have all of
this information from the start instead of requiring readers to extract all of
this.