Re: Path forward for Virtualized Swap?
From: Gregory Price
Date: Sat Sep 19 2026 - 21:53:25 EST
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@xxxxxxxxxx> wrote:
> >
> > 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.
No. That is not what I said.
I said
It's the *amount* of memory consumed by compressed data,
including the metadata associated with it.
I do not know how to be clearer than this. It is an amount of memory.
It is not the memory itself or an abstraction to describe how much
memory, it is literally the active amount of consumption - a number.
> Maybe we need a separate counter to track actual memory usage,
> regardless of compression status.
the separate counter is... the existing memory and zswap counters.
> 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.
>
I want:
1) zswap on machines with no swapfile
2) without being asked "how big?" - there is no number I can give
that stays correct, and
3) the bound should be the memory limit that already exists,
not a number guessed at boot that hotplug invalidates or
guessed at swapon time that different workloads invalidate.
This requires decoupling swap *file* accounting from zswap accounting.
~Gregory