Re: Path forward for Virtualized Swap?

[Johannes Weiner]

On Tue, Sep 22, 2026 at 01:14:31PM -0400, Rik van Riel 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>
> > > 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.
> 
> That seems like the kind of limit that is large
> enough that very few people will run into it, 
> while also being small enough to prevent actual
> corner case trouble.

Just to be sure we're all on the same page:

Zswap *backing memory*, the space needed for compressed data, is not
the problem. It actually has a limit that defaults to 20% of
memory. And there is memory.zswap.max for users to define everybody's
fair share of that limited backing storage.

The point of conflict is the pre-compressed side. How many swap
entries can vswap hand out. Hard limiting this is the point of
conflict. Any given swap entry can refer to several things: a page
full of zeroes that has no backing space; a compressed page in zswap
that consumes some amount of backing space; a page that was written
back from zswap and now consumes physical swapfile space.

All mapped by the same address space.

I don't see why you would limit this at all. I don't see how you would
pick a sane default. And if you limit it and workloads run into it,
there are no cgroup controls to manage fair access.

(Despite what has been said in this thread, memory.swap.max is for
those entries that compete over physical swapfile space. It must not
and can not control vswap space used for all sorts of backends.)