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

[Nhat Pham]

On Wed, Oct 28, 2026 at 6:48 PM Sergey Senozhatsky
<senozhatsky@xxxxxxxxxxxx> wrote:
>
> On (26/10/29 10:43), Sergey Senozhatsky wrote:
> [..]
> > > Hmm we'd need to collect more data in our workloads to determine, but
> > > if we can compute compactable ratio (freeable_pages / total_pages) on
> > > a per size class basis, can we just skip the size class whose ratio is
> > > too bad? Would that at least cut down on the vast majority of
> > > fruitless memcpys and lock acquisitions etc?
> > >
> > > I'm always a bit hesitant to over-rely on userspace, especially when
> > > kernel has information to do something smart about it. It might not
> > > react in time, and many proactive reclaiming schemes back off under
> > > heavy memory pressure.
> >
> > Apologies for the delay.
> >
> > The thing about shrinker compaction is that it's sort of on the
> > wrong end.  It doesn't trigger compaction when memory is plentiful,
> > no matter the internal fragmentation rate, and start firing compaction
> > scans when memory pressure hits.  The problem with this is that, now
> > compaction moves objects (if can compact zspages) and releases empty
> > zspages, in parallel with potentially heavy swapping out activities,
> > which can simply allocate those released pages back.  Which seems like
> > a useless exercise and needless memcpy-s.  So I was thinking about
> > either putting it under config or just removing it (this might be a
> > harder decision).

Hmmm I suppose if the new objects belong to the fragmented size class,
then there is no point in doing defragmentation, because the new
objects will fill the holes.

If they are of different size classes though it's a win to free these
fragmented zspages and reallocate them to the size classes of the
incoming objects right?

I can't really say which is more likely without data... And it might
be workload/reclaim-behavior dependent...

(The size class check for fragmentation level to skip internal
compaction is nice here because is agnostic to distribution and
trigger points. We should land that regardless).

>
> In embedded (android/bookOS/etc.) there is a daemon, that triggers
> various zram activities.  We can wire in pool-compaction (once under
> memory pressure), which is a zram sysfs device attribute, instead
> of pondering zsmalloc with scan callbacks.

Internally we use senpai, which trigger memory reclaim when there is
no memory pressure, to reclaim cold data (which in turns trigger
zsmalloc compaction).

It still does both zswapping and zsmalloc compaction in the same
round-ish though.