Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Mon, Sep 21, 2026 at 3:01 AM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> On Sat, Sep 19, 2026 at 9:02 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
> >
> > On Sat, Sep 19, 2026 at 6:08 AM Gregory Price <gourry@xxxxxxxxxx> 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 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. A page fault adds significant latency to memory access
>
> Yeah I agree on this. Swap just about makes resources not directly
> accessible by the CPU act as RAM, whether that is storage on disk,
> compressed memory, or a network resource, all accessed through a page
> fault. I hope we won't make this fuzzy in the future by introducing
> too many magics.

memcg folks should chime in, but IMHO the cgroup swap limits are there
because we want to provide proper isolation and fair distribution of a
limited, static resource among co-tenants. And without vswap, this is
true with all swap backend and all swap usage, because they all occupy
that limited resource. So charging makes sense in the old setup.

This is not the case with vswap. The vswap slot by itself does not
consume any meaningfully limited resource with the vswap device. When
it acquires a backend, we still gate the resource that backend is
occupying for fairness and isolation (swap.max, zswap.max, the latter
of which arguably is unneeded/harmful outside of 0/max).

Charging vswap arbitrarily towards swap.current opens up new avenue of
contention that is farcical. For instance, a workload's disk swap
usage contends with its zswap usage. Or if a cgroup's zswap usage can
potentially contend with another cgroup's disk swap usage, even though
actually contend with no physical resource. It makes no sense.

If we're talking about confusion, I would argue that the current
design *is* more confusing. We have to answer to users constantly why
zswap is occupying swap even if there is no IO/disk involved. And, we
have a boot parameter - if you turn that on, then you get new
behavior. We can add more documentation, but I don't think we need
more machinery for that.