Re: Path forward for Virtualized Swap?

[Chris Li <chrisl@kernel.org>]

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 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
compared to access without one. Whether the memory is backed by SSD or
compressed RAM, this is an invariant of that definition. If you change
the behavior by not charging to swap when swapping out to compressed
memory, it will break our deployment, causing many OMGs. Kairui also
mentioned that this will break their usage as well.

Therefore, I must push back on this. Please don't change the swap
counter charging behavior due to the risk of SLO violations for users.
This is a user-visible behavior change.

Secondly, I notice that you are reasoning from the memory usage
aspect. That is a different usage requirement angle than the SLO
violations. Maybe we need a separate counter to track actual memory
usage, regardless of compression status.

Let's figure out a way to make your usage case work as well, not at
the cost of breaking existing usage requirements from an SLO violation
perspective.

> Baking any kind of pre-defined limit *into the infrastructure* (whether for
> an optimization or ease of implementation) is what requires users to know
> what compression space is.
>
> Even using memory capacity at boot as a limit is wrong - hotplug exists.

This reinforces the point that viewing things through the lens of
"compression space" is confusing and muddy. That is not my mental
model. I want to add support for your usage case as well. Please
clearly specify what user usage you want, what the expected outcome
is, and why you want that.

>
> > Why does the user need to care about compression space again?
>
> They shouldn't need to, that's very much the point.

Great, Sounds like I can safely bypass it.

Chris