Re: Path forward for Virtualized Swap?

[Chris Li]

On Tue, Sep 22, 2026 at 7:33 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2026 at 8:23 AM Chris Li <chrisl@xxxxxxxxxx> wrote:
> >
> > On Tue, Sep 22, 2026 at 4:59 AM Rik van Riel <riel@xxxxxxxxxxx> 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. My point is
that 100% is not a usable metric. I suspect your deployment doesn't
have machine zswap even close to that amount. Glad to be proven wrong
with some real data points.

>
> "Trigger different kernel code path on allocating memory" what do you
> mean by this? This reads like you're referring to post-compression
> size, where one cgroup eats up the RAM of the host, affecting other
> tenants in that host. But putting a limit on the virtual device
> capacity limits the PRE-compression footprint. It is a very
> unpredictable way to prevent the effect you're referring to above,
> because compression ratio is unpredictable ahead of time.

I mean triggering the direct reclaim path because zswap itself can't
allocate memory for the swap cache to serve the page fault.

Chris

> For post-compression size, I can make arguments on why we should not
> also gate it, but regardless we already have zswap.max and the global
> zswap pool limit.