Re: Path forward for Virtualized Swap?

[Gregory Price <gourry@gourry.net>]

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


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

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.

> Why does the user need to care about compression space again?

They shouldn't need to, that's very much the point.

~Gregory