Re: Path forward for Virtualized Swap?

From: Chris Li

Date: Wed Sep 23 2026 - 03:31:51 EST


On Tue, Sep 22, 2026 at 7:21 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2026 at 10:15 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
> >
> > On Mon, 2026-09-21 at 06:11 -1000, Chris Li wrote:
> > > On Mon, Sep 21, 2026 at 2:53 AM Gregory Price <gourry@xxxxxxxxxx>
> > > wrote:
> > >
> > > >
> > > > You can't know the compressibility of memory until after you
> > > > compress
> > > > it, and requiring a user to predict the future by forcing them to
> > > > limit
> > > > the total amount of workload compressibility does not scale with
> > > > the
> > > > number of workloads of variable compressibility of data.
> > >
> > > You likely just need to pull a SQL query on your fleet to get that
> > > number.
> >
> > This feature is not being developed for just one
> > user. It has to work for everybody.
> >
> > >
> > > > That should tell you that your model of reasoning about this issue
> > > > is
> > > > ill-suited to address the problem.
> > >
> > > That is what I'm suspecting. Nobody in a sane mind would want to
> > > zswap
> > > 100% of the RAM and maintain reasonable SLO.
> > >
> > It could make a lot of sense to have some default
> > limit upstream, that says the zswap pool is not
> > allowed to take more than half of memory, because
> > at that point the compressed content will be
> > crowding other things out of memory.
>
> I actually am skeptical of gating zswap usage (both pre- and

Isn't there a zswap limit some thing like that? In our deployment we
have limits for memory + swap as well as page fault latency to detect
SLO issues. There is a feedback loop.

> post-compression), but I would like to note that for post-compression
> size, we already have that knob for zswap, default to 20% of physical
> RAM.

I think swapping too much to zswap does not make sense. e.g. 100% of
system RAM. That is my point. It is not a value you cannot determine.
We can find an universal answer with a safe margin if we want. That is
my point: it's not a value you can't determine. We can find the answer
with a safe margin if we choose to. If you don't want to, then that is
a different story.

Chris