Re: Path forward for Virtualized Swap?

[Johannes Weiner <hannes@cmpxchg.org>]

On Tue, Sep 22, 2026 at 09:37:48PM -1000, Chris Li wrote:
> On Tue, Sep 22, 2026 at 7:33 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Tue, Sep 22, 2026 at 8:23 AM Chris Li <chrisl@kernel.org> wrote:
> > >
> > > On Tue, Sep 22, 2026 at 4:59 AM Rik van Riel <riel@surriel.com> wrote:
> > >
> > > Yes, I can agree on what you observed. You are using anon + zswap on
> > > that app alone. That is not what I originally asked.
> > >
> > > My original request was for the whole system: what percentage of the
> > > total system RAM size has been swapped out to zswap.
> > >
> > > Because when you have 100% of zswap out, it will likely trigger
> > > different kernel code path on allocating memory. You might suffer
> > > global memory pressure you did not observe in the single app memory
> > > pressure case.
> >
> > What does this 100% figure refer to? Pre- or post- compression size? I
> > legitimately cannot tell.
> 
> The 100% I mentioned above refers to the pre-compression size. See my
> previous email in this thread for details. I have been asking for a
> max(%) number in your fleet for more than six emails now.

Because people keep telling you that it's immaterial. The job of the
compression layer is to make pages smaller. It has no business
deciding what is "too much", what is "too hot". That's the job of
reclaim and OOM killing. That's the job of cgroup residency controls,
of things like MGLRU's min_ttl.

You have absolutely no way of knowing what a safe threshold is for
every usecase now and in the future.

The argument isn't we need a bigger limit. And I refuse to haggle with
you over what the precise value should be.

The argument is a to use an xarray and keep making pages smaller while
the policy layers deem it reasonable to do so.