Re: Path forward for Virtualized Swap?

[Johannes Weiner <hannes@cmpxchg.org>]

On Tue, Sep 22, 2026 at 09:32:17PM -1000, Chris Li wrote:
> On Tue, Sep 22, 2026 at 7:31 AM Johannes Weiner <hannes@cmpxchg.org> 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@gourry.net>
> > > > > 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?

If you look at the git tree, you'll find it came in with the original
commit that introduced zswap. There was no explanation.

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

Yes, thank you:

" the practical usecase for limiting zswap memory to begin with is
  quite unclear to me. Zswap is not a limited resource. It's just
  memory. And you already had the memory for the uncompressed copy. So
  it's a bit strange to me to say "you have compressed your memory
  enough, so now you get sent to disk (or we declare OOM)". What would
  be a reason to limit it? "

- https://lore.kernel.org/linux-mm/20240925192006.GB876370@cmpxchg.org/

This is my whole point. Swap/compression is a low level layer in the
reclaim stack. You're asking it to make a page smaller and it does it.

- It's *reclaim* that determines who and how much gets swapped.

- Cgroups provide configurable memory.low and memory.min residency
  enforcement based on volume.

- MGLRU has the min_ttl setting to configure residency based on
  hotness.

- Many real world environments use some form of pressure-based OOM
  killing to determine when too many pages have become non-resident
  and the workload meets some subjective threshold of "suffering".

There is a whole stack of clever algorithms and configurable QoL
policies that make judgements about residency.

The compression layer has one job: compress the pages I feed you. It's
purely mechanical. It does not need an opinion on which pages are hot,
how much compression is "too much". It's a glaring layering violation.

The reason we keep talking past each other is that you think I'm
arguing for a larger limit. I am not. I'm saying the mechanical
compression layer has no business editorializing what the policy
layers above it have determined.

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

And this would carry a lot of weight if we HAD to go with vmalloc.

But there is an alternative proposal based on xarray that does not
have that limitation at all. Neither Nhat nor Boaquan seem to have
been able to find any performance issues with it.

It's YOUR claim that we need to go the vmalloc route. That means it's
YOUR burden to (1) propse an implementation limit that everybody
agrees is safe and (2) why the usability risk of having a limited
implementation is even justified (e.g. performance numbers).

You clearly haven't done either.

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

No. This has been explained to you repeatedly.

It's for managing fair access to a physical swapfile space because
that's a constrained resource.

After vswap, zswap does not use physical swapfile space anymore. But
other things will, and it's important it keeps working for them.

This "user-visible behavior change" is the whole dang point.

And it's opt-in, so nobody "breaks" through kernel upgrades.

I'm sorry if your setup is abusing this knob for enforcing some sort
of residency. This isn't what it was designed for, and it is clearly
not a generalizable model - most workloads have page cache.

You're in fact asking for it to STOP being usable for managing
physical swapfile space. You're asking to break the broader container
and memory management model as designed so you can continue supporting
what is essentially a case of creative abuse.

This is unreasonable.