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

From: Barry Song

Date: Tue Nov 03 2026 - 19:08:21 EST


On Wed, Nov 4, 2026 at 7:42 AM Ababneh, Ehab <ehab.ababneh@xxxxxxxxx> wrote:
>
> Hi all,
>
> I would appreciate your thoughts on how we might achieve a similar
> performance improvement without increasing the number of kswapd
> threads.
>
> In the previous patchset, using four kswapd threads reduced Cassandra
> p99 latency from 6.5 ms to 3.35 ms (about 48%) and improved throughput
> by 10.3%. I believe this is a substantial result and worth pursuing
> further.

Hi Ehab,

I assume the performance improvement mainly comes from
reducing direct reclaim by using four async threads to
reclaim memory. Is that correct?

>
> To explore alternatives, I tried increasing the reclaim target for
> kswapd passes (testing multipliers from 2 to 100), shortening kswapd's
> sleep intervals, and making it more patient before declaring a node
> hopeless. So far, none of these approaches has produced a comparable
> improvement.

So basically, one thread isn't sufficient to reclaim memory
in time, causing your workloads to fall into direct reclaim
frequently?

>
> I would be grateful for suggestions on other approaches worth
> investigating.

We have various types of proactive reclaim that can run
asynchronously in parallel:

1. Memcg proactive memory reclaim
2. Node proactive reclaim
3. recently, Hui Zhu even provides a bpf-based reclamation:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48ea1ba704aa3a9

We have these approaches that allow userspace to
flexibly ramp up reclaim before we have to fall back to
direct reclaim.

Also, if you're using zswap or zram, compression itself
could be the bottleneck.
There was a proposal for kcompressd to handle compression
asynchronously, which has been on hold for a while:

https://lore.kernel.org/linux-mm/20250430082651.3152444-1-qun-wei.lin@xxxxxxxxxxxx/

Or, if aging is your bottleneck, perhaps something like
async aging could help?

I'm still not sure where the performance improvement
comes from. Is it mainly due to reduced direct reclaim?

Best,
Barry