Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Wed, Sep 23, 2026 at 12:38 AM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> 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.

My point is that it's an invented problem because of the interface you chose.

My interface does not require setting any such number or cap from
userspace perspective. The only cap is based internal
implementation-driven.

You're the one proposing an interface with static limit. You're the
one who have to justify a) why we need that limit in the first place,
because that's more work for userspace and b) why the default value
makes sense.

>
> >
> > "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

Then it's out of memory...? If you couldn't zswap those pages then it
would just OOM earlier?

If those same pages are not in (z)swap you would have bigger
footprint? I don't understand what's your concern here.