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

[Nhat Pham]

On Wed, Nov 4, 2026 at 11:46 AM Chris Wiseman <chriswiseman@xxxxxxxxxx> wrote:
>
> On Wed, Nov 4, 2026 at 9:57 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > 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!
>
> Yeah, it just checks if a bucket has enough wasted slots to free at
> least one full page before taking the locks.  Sergey pointed out those

You meant full zspage here right? IIUC we keep the entire chain of
zpages around until the entire zspage is gone?

> two counters aren't atomic together so an unlocked check is just a
> best-effort hint - if you and Sergey are good with that, happy to send a
> patch.

Personally I'm happy with it being a best-effort hint!

We can also recheck after we acquire the lock (but I suspect it's
unlikely we'll get radically different decision?)

Sergey, how do you feel about this?

>
> > 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?
>
> Compaction still helps when we trigger it between bursts (freed ~21 MB
> before the swap storm and ~10 MB after).  It just wastes time running
> mid-swap when new writes are filling those open slots right back up.
> Defaulting CONFIG_ZSMALLOC_SHRINKER to N (or CONFIG_ZSWAP) for a couple
> releases makes sense to me.

SGTM, but I'll let Sergey chime in!