Re: Path forward for Virtualized Swap?

[Kairui Song]

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.