Re: Path forward for Virtualized Swap?

[Chris Li]

On Sat, Sep 19, 2026 at 3:53 PM Gregory Price <gourry@xxxxxxxxxx> wrote:
>
> 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.

Sure the amount, that is what I have in mind as well. That is why I
said swap counter.
>
> It is not the memory itself or an abstraction to describe how much
> memory, it is literally the active amount of consumption - a number.

Yes, compress zswap counter.
>
> > 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.

Exactly. So, did that solve your problem? If not, why not?

>
> > 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:

I am sorry, that is not actual user usage. You need to start from an
actual usage case: I have a workload X, only want to give limit Y for
the cgroup jobs but with Z SLO requirement. That kind of actual usage
requirement.

You are basically saying you want a pony. I also want an antimatter
pony. Let's battle with our ponies.

>
>   1) zswap on machines with no swapfile
>
>   2) without being asked "how big?" - there is no number I can give
>      that stays correct, and

Because you can't answer a question, we have to bend over backwards
for you? That does not make sense. There are a lot of questions I
can't answer either; that does not make my pony request more legit.
Apparently, you can't even answer what max(%) of RAM you swap out to
zswap in your fleet. One way to get that answer is to find out what
that % number in the fleet across different years, then you can pick
up the trend and leave a safe margin. FYI, in our case, that number
has been stable for our deployment over many years.

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

I am sorry, that feels like a rule you invented.

Let's start with the real question: on your fleet what is the max % of
zswap memory compared to total RAM?

I am not designing the swap system for hypothetical situations. I
design it for actual usage. Hypothetical solutions suffice for
hypothetical usage. No patches needed.

As you can tell, I am less interested in the hypothetical solutions
discussion. It is not the best use of my time.

>
> This requires decoupling swap *file* accounting from zswap accounting.

What are your thoughts on current deployment usage depending on the
zswap charge to the swap counters? Changing that will be a
user-visible behavior change and could break other existing
deployments.

Chris