Re: Path forward for Virtualized Swap?

[Johannes Weiner <hannes@cmpxchg.org>]

On Sat, Sep 19, 2026 at 09:02:28AM -1000, Chris Li wrote:
> On Sat, Sep 19, 2026 at 6:08 AM Gregory Price <gourry@gourry.net> wrote:
> >
> > On Sat, Sep 19, 2026 at 03:45:03AM -0500, Chris Li wrote:
> > >
> > > I found this new concept of "compression space" very confusing to me.
> > > Can you explain the swap behavior and problem using only normal memory
> > > usage reduction and latency without introducing a new term or new
> > > metrics?
> > >
> > > The normal user doesn't even know what compression space is, let alone
> > > what makes it transparent.
> > >
> >
> > Sure they do - it's the amount of memory consumed by compressed data,
> > including the metadata associated with it.
> >
> > converting Johannes statement to diagram:
> >
> > >> Compression space is not a separate resource. It's page tables,
> > >> backing pages, and swap descriptors. It's just MEMORY.
> >
> >                           Page Data (PD)
> >   [page tables][                uncompressed page                  ]
> >
> >
> >                         Compressed Data (CD)
> >   [      recovered space     ][pte][swap meta data][compressed page]
> >                               |                                    |
> >                               |---------compression space----------|
> >
> >
> >                         Memory Pre-Compression
> >  |[  PD  ][  PD  ][  PD  ][  PD  ][  PD  ][  PD  ][  PD  ][  PD  ]|
> >
> >
> >                         Memory Post-Compression
> >  |[CD][CD][CD][CD][CD][CD][CD][CD]-------- free space ------------|
> >    ^----------------------------^
> >          Compression Space
> 
> Thanks for the explanation. So the compression space is just the
> actual data store backing the zswap/xswap/zram.

It's actually the pre-compression side I was referring to. The address
space that vswap/xswap map.

If you artificially hard limit this *address space*, you are making
assumptions about (1) compression ratio and (2) how much non-residency
the workload can tolerate. You might well get real workloads hitting
that limit while you'd still have the ability to store more.

Add pressure-driven writeback in the mix, and now even compression
ratio assumptions are not useful: The stuff in zswap compresses a
certain way and the stuff that was written back is out of memory
completely.

Yet it's all mapped by that same address space.

How could anyone pick an informed size limit for this space?

How many setups hard-limit the process virtual address space to 2xRAM?
Nobody. They limit the physical memory required to back it. That's the
only thing that actually matters.

> > It's actually really confusing to represent this space as a traditional
> > swap device - built on the assumption of a pre-defined size limit - when
> > that size limit has already been defined (the memory itself).
> 
> First of all, the traditional swap counter has a very well-defined
> meaning. It is the size of the memory that, when accessed, requires a
> page fault.

That's 100% wrong.

First of all, it wouldn't work because you can still take page faults
on the filesystem.

Second, this is absolutely not their intended purpose. They are to
control access to a physically limited swapfile on disk. Because it is
a discrete, separate resource from memory. That's the whole reason why
memory and swap controls were split in cgroup2. I designed this.

What you're talking about is residency guarantees. This is what
memory.min and memory.low are for.