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

[Yosry Ahmed]

On Thu, Nov 5, 2026 at 7:38 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> 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.

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!