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

[Nhat Pham]

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).

How do you feel about this, folks?