Re: [RFC PATCH 0/2] mm: zsmalloc: make shrinker compaction budget-aware
From: Chris Wiseman
Date: Thu Nov 05 2026 - 12:04:58 EST
On Thu, Nov 5, 2026 at 7:40 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> Never mind the compaction argument, this is just to move zsmalloc
> pages around, it doesn't help with internal fragmentation. -ENOCOFFEE.
>
> I still think we should check if the zsmalloc shrinker actually helps
> zswap or not tho!
I ran a quick test with zswap turned on to check.
Yosry is right - as long as new pages are swapping out, zswap naturally
refills the freed slots on its own. Both runs ended up at the exact
same 95 MB pool size, and turning the zsmalloc shrinker off cut page
fault latency by 26% because reclaim isn't fighting itself for the same
locks.
The only time the shrinker actually saved memory in zswap (~20.8 MB) was
when I blocked new swap-outs completely after punching holes, since
zswap doesn't have a manual sysfs compact knob like zram.
ARM64 QEMU (Linux 7.3.0+, 4 vCPUs, zswap lz4):
Shrinker ON Shrinker OFF
Active swap-out pool size: 95.9 MB 95.1 MB
Active swap-out p50 fault: 3,262 us 2,414 us (-26%)
Idle pool (swap-out blocked): 44.2 MB 65.1 MB (+20.8 MB)
Maybe we go with Nhat's idea (CONFIG_ZSMALLOC_SHRINKER defaulting to
ZSWAP_DEFAULT_ON) for now, and if zswap adds a proactive compact knob
later we can just kill the shrinker?