Re: [PATCH] mm/vmscan: clear hopeless kswapd when global direct reclaim makes progress

[Altan Hacigumus]

On Thu, Jul 9, 2026 at 8:22 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu,  9 Jul 2026 19:44:29 -0700 Altan Hacigumus <ahacigu.linux@xxxxxxxxx> wrote:
>
> > Direct reclaim clears the hopeless kswapd state only once the node
> > becomes balanced. This avoids cgroup memory.high reclaim repeatedly
> > reviving a kswapd that cannot balance the node.
> >
> > However, it also prevents global direct reclaim from reviving kswapd.
> > Under sustained memory pressure, global direct reclaim may continue
> > making progress without the node ever reaching the high watermark,
> > leaving reclaim to allocating tasks.
> >
> > Unlike memcg reclaim, global direct reclaim follows the same node-wide
> > reclaim path as kswapd. Clear the hopeless state when global direct
> > reclaim makes progress, while continuing to require a balanced node for
> > memcg reclaim. kswapd_try_clear_hopeless() becomes static since struct
> > scan_control is private to vmscan.c.
> >
> > On a workload with most memory mlocked and the remainder under sustained
> > churn, with swap enabled, comparing the same 60s window:
> >                               base       patched
> >   allocstall (all zones)    413441          6532
> >   pgsteal_direct          15889552        255619
> >   pgsteal_kswapd                 0      26079382
> >   PSI memory full avg60     13.10%         9.37%
> >
> > Direct reclaim was already reclaiming many pages in the baseline;
> > this change lets kswapd resume doing that work asynchronously.
>
> Does this change have any user-visible effect?  If so, please describe
> in elaborate detail.
>

Yes, the effect is visible on systems where a db workload mlocks 80%+
of memory and the remaining memory is under continuous pressure:
allocations stall long enough that ordinary tasks (e.g. ssh) become
slow or unresponsive.

> If not then that's OK - we make such changes all the time, but they're
> less fun.
>
This was introduced by commit dc9fe9b7056a; for long before it, any
reclaim progress revived kswapd. Now only a balanced node clears the
hopeless state, which is too restrictive for global direct reclaim.

Thanks,
  Altan