Re: [RFC PATCH 0/2] mm: zsmalloc: make shrinker compaction budget-aware

[Nhat Pham]

On Mon, Nov 2, 2026 at 1:24 PM Chris Wiseman <chriswiseman@xxxxxxxxxx> wrote:
>
> On (26/11/02 08:47), Sergey Senozhatsky wrote:
> > Adding Chris for visibility
>
> Thanks for looping me in, Sergey.
>
> I tested your CONFIG_ZSMALLOC_SHRINKER=n patch in ARM64 QEMU (7.3.0+, 16
> boots per arm) by fragmenting zram0, triggering a manual compaction pass
> at pressure onset via /sys/block/zram0/compact, driving ~240 MB of
> swap-outs under memory pressure, and running a post-swap manual
> compaction pass.
>
> Your theory holds up: with the shrinker enabled, the kernel compacted
> 2,218 pages (~9 MB) in the middle of the swap-out, only for incoming
> swap-outs to immediately reuse those pages.  With
> CONFIG_ZSMALLOC_SHRINKER=n, mid-swap compaction dropped to 0 and zram
> pool memory was identical both during the swap-out (120.9 MB vs
> 121.0 MB) and after manual compaction (110.9 MB vs 111.2 MB).
>
> I also tested adding the unlocked zs_can_compact() pre-check in
> __zs_compact() on top of CONFIG_ZSMALLOC_SHRINKER=n, which cuts each
> userspace /sys/block/zram0/compact scan from 97 us to 27 us:

Is this precheck basically checking if we can free at least one zspage
of the size class before proceeding? Yeah the number looks good -
let's add that, in parallel!

>
>                                   Shrinker ON   Shrinker OFF   Shrinker OFF + pre-check
>   -------------------------------------------------------------------------------------
>   Pages compacted mid-swap              2,218              0                          0
>   zram mem_used_total (mid-swap)     121.0 MB       120.9 MB                   121.1 MB
>   zram mem_used_total (post-compact) 111.2 MB       110.9 MB                   111.1 MB
>   /sys/block/zram0/compact scan time    96 us          97 us                      27 us
>
> Representative /sys/block/zram0/mm_stat snapshots:
>
> BASE (CONFIG_ZSMALLOC_SHRINKER=y)
>   pre_onset:         184553472  58747279   82350080  0   82374656  0      0   0   0
>   onset_compact:     184553472  58747279   60456960  0   82374656  0   5345   0   0
>   after_swap_out:    334196736 107289761  120946688  0  120946688  0   7570  29  29
>   post_compact:      334749696 107472834  110907392  0  120946688  0  10016  29  29
>
> PATCHED (CONFIG_ZSMALLOC_SHRINKER=n)
>   pre_onset:         184553472  58747279   82350080  0   82374656  0      0   0   0
>   onset_compact:     184553472  58747279   60456960  0   82374656  0   5345   0   0
>   after_swap_out:    334372864 107347183  120922112  0  120922112  0   5345  29  29
>   post_compact:      334995456 107550158  111009792  0  120922112  0   7767  29  29


Ah ok hmm. Sounds like internal compaction isn't that helpful, i.e
zsmalloc already does a pretty decent job at packing objects that
there aren't a terrible amount of internal fragmentation in the first
place...?

Should we do CONFIG_ZSMALLOC_SHRINKER (default to N or to
CONFIG_ZSWAP) for now, and remove it in a couple of releases if users
in the wild do not complain?