Re: [RFC PATCH v2 0/5] mm/vmscan: adaptive multi-threaded kswapd for NUMA-aware reclaim

[Barry Song]

On Sat, Oct 10, 2026 at 4:30 AM Ehab Ababneh <ehab.ababneh@xxxxxxxxx> wrote:
>
> This is a follow-up to the RFC for adaptive multi-threaded kswapd
> on NUMA. It handles concurrent MGLRU aging, adjusts wakeups to node
> CPU load, and scales the hopeless threshold for multiple workers.
>
> Under memory pressure, an lruvec can end up with only two MGLRU
> generations. That leaves an older and a younger cohort, a bit like
> inactive and active LRU lists, though MGLRU tracks age differently.
>
> Regarding the concerns raised in review:
> - In the updated Cassandra comparison, four kswapd threads reduced p99
>   latency from 6.5 ms to 3.35 ms (about 49%) and increased throughput by
>   10.3%. We believe the latency gain comes from the reclaim design,
>   not from changes to LRU locking.
> - This newer result compares four kswapd threads with one. The earlier
>   7.3% throughput result was measured with eight threads.
>
> We also saw periods with zero file scans. The MIN_NR_GENS guard may
> contribute: when only two generations remain, it makes scan_folios()
> return without scanning the oldest one. This patch tests whether letting
> kswapd scan that generation helps reclaim progress. The current traces
> do not tie the zero-scan events to the same lruvec, so this remains a
> hypothesis; more per-lruvec tracing is needed to compare it with lock
> contention.

Hi Ehab,

There is a patchset under development by Kairui, me and gaofei:

https://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git/log/?h=kairui_scanbalance_0.3

which allows reclamation after we arrive MIN_NR_GENS.

This might fix your problem. Hopefully, we can find some time next
week to send it out.

Thanks
Barry