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

[Yosry Ahmed]

On Thu, Nov 5, 2026 at 7:08 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Thu, Nov 5, 2026 at 6:36 AM Chris Wiseman <chriswiseman@xxxxxxxxxx> wrote:
> >
> > On Wed, Nov 4, 2026 at 9:05 PM Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote:
> > >
> > > On (26/11/05 09:10), Xueyuan Chen wrote:
> > > [..]
> > > > > SGTM, but I'll let Sergey chime in!
> > > >
> > > > Thanks, Nhat and Chris, for the discussion.
> > > >
> > > > If Sergey has no objections, I'd be happy to send a follow-up series
> > > > to make the shrinker configurable and add the unlocked pre-check as
> > > > Nhat suggested.
> > >
> > > Thanks.  Sounds like you and Chris will to have "Rock-Paper-Scissors"
> > > to determine who sends a oatch ;)  Just joking, let's first figure
> > > out how exactly we want that zsmalloc-shrinker thing to behave wrt
> > > zswap expectations.
> >
> > Haha, Xueyuan is welcome to send the patches!
> >
> > Dumb question on the zswap side - aren't the zswap shrinker and the
> > zsmalloc shrinker independent?  Even if zswap's shrinker is turned off
> > at runtime, normal swap-ins still free slots and leave fragmentation
> > behind, and unlike zram, zswap doesn't have a manual sysfs compact knob.
> > Would it be simpler to just keep CONFIG_ZSMALLOC_SHRINKER as its own
> > standalone config rather than tying it to zswap's runtime knob?
>
> Yeah those 2 shrinkers are independent! I think we should just let
> ZSMALLOC_SHRINKER default to the value of ZSWAP_DEFAULT_ON.
> zswap_load() (i.e zswap-in) by itself is enough to create
> fragmentation. The zswap shrinker is just another trigger (and it's
> also irrelevant if zswap is disabled anyway).

If zram doesn't benefit from zsmalloc shrinker, especially during
reclaim, I wonder how much zswap benefits. AFAICT, it was hooked up
before zsmalloc was hooked into compaction, and compaction seems like
the right place to do this although it technically is freeing pages
from the page allocator's perspective.

I wonder if this is something we can collect some data about, and
maybe kill it off instead of putting off behind a config option. If
hooking it into compaction is not enough, maybe we should add a
similar interface in zswap to do proactive pool compaction from
userspace, or maybe move the interface to zsmalloc itself.

>
> How do you feel about this, folks?