Re: Path forward for Virtualized Swap?

[Gregory Price <gourry@gourry.net>]

On Thu, Sep 24, 2026 at 01:02:54AM -1000, Chris Li wrote:
> >
> > It's hard to say. When 37e84351198b ("mm: memcontrol: charge swap to
> > cgroup2") introduced memory.swap.*, it was clearly defined as charging
> > "the actual number of swap entries used by a cgroup". Please see the
> > commit log. With that, zswap still reserved a swap slot even when the
> > data never reached disk. And not to mention zram, it's backend is RAM,
> > but not physical disk.
> 
> Right, that definition matches what I have in mind. The actual number
> of swap entries regardless of the backing type.
> 
> Changing the meaning of that breaks existing users.
> 

Except that you are the one proposing the change in definition.

You conveniently skipped the message where I laid out, in detail,
why this interpretation is not grounded in either the documentation
or in the introduction of the counter.

You do not redefine contracts because "that's what you have in mind".

> > Now some deployments do use memory.swap.* as an SLO signal, and that is
> > real use cases as Chris and Kairui told. So I don't think this is about
> > who is right and who is wrong.
> >
> > To keep the existing deployment working and at the same time give the
> > physical slot its own knob, I think the solution is to add a memory.pswap.*
> > counter as you suggested. And that is not something we think of from a
> > brain storm, it comes from real deployments which already depend on the
> > current memory.swap.* behavior.
> 
> I think it is important not to break the existing usage of
> memory.swap.* behavior. I am fine with adding another counter.
> 

Then you should stop distracting everyone and propose your solution and
make the argument for redefining the counter to mean "what you have in
mind" and justify the addition of the new interface.

I think there is merit in the argument - both Johannes and Rik have
some concerns whether it makes sense.  There's something to discuss.

But the core issue here is that your use case is counter to documented
purpose of the counter, and just because you can derive meaning in
combination with another counter does not mean that is contractually
guaranteed by the ABI.

If you want to make the argument that it is, in fact, contractually
guaranteed by the ABI - then this is a different discussion, and the
introduction of memory.pswap would be tangential to vswap (though it
would enable vswap=on to be the default without breaking anyone).

Seek a way forward, not a way to stonewall.

~Gregory