Re: Path forward for Virtualized Swap?

[Chris Li]

On Tue, Sep 22, 2026 at 7:31 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> 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.

Just curious, how is the 20% determined? May I apply the same argument
used in this thread: since you haven't surveyed all users in the world
so you can't determine that 20% is a good value. Let's make that 200%
for safety.

Clarify, I am not actually challenging the 20% value. I am trying to
see if I can use the same method you used to decide on 20% to convince
you that there can be a similar upper bound for the amount of swap
space.

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

I am not using a limit to enforce the workload. I am just using the
limit with a safe margin to set the vmalloc max size for xswap. This
is similar to the 20% for the compressed pool. I do believe the app
will suffer if too much of its memory is swapped out. e.g. 100% of
system RAM.

> (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.)

Doesn't memory.swap.max limit existing zswap? Then that is a
user-visible behavior change to make zswap don't go through the swap
counter. That is a change we need to avoid.

Chris