Re: Path forward for Virtualized Swap?

[Gregory Price]

On Wed, Sep 23, 2026 at 05:39:44PM +0800, Baoquan He wrote:
> > 
> > That's an SLO interface.  memory.swap is a provisioning interface.
> > 
> > As it stands, I'm left viewing zswap's counter inclusion in swap as more
> > of a bug than a feature - they account for different things (memory vs
> > storage usage).
> 
> 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.
>

If you read the entire series, you will find this documentation update
to go along with that commit:

https://lore.kernel.org/linux-mm/dbb4bf6bc071997982855c8f7d403c22cea60ffb.1450352792.git.vdavydov@xxxxxxxxxxxxx/

  For trusted jobs, on the other hand, a combined counter is not an
  intuitive userspace interface, and it flies in the face of the idea
  that cgroup controllers should account and limit specific physical
  resources.  Swap space is a resource like all others in the system,
  and that's why unified hierarchy allows distributing it separately.

So the counter was also intended to be a limit on swap space - not a
limit on the amount of virtual memory allowed to be swapped (via any
backend).

Johannes originally proposed this for the documentation:

https://lore.kernel.org/linux-mm/20151211194254.GF3773@xxxxxxxxxxx/

  memory.swap.current

       The amount memory of this subtree that has been swapped to
       disk.

  memory.swap.max

       The maximum amount of memory this subtree is allowed to swap
       to disk.


It is clear from the outset that memory.swap was intended as a resource
consumption control (how many swap entries may be used), not as a
virtual memory consumption limit (how much memory can be swapped).

all the v1 discussions you will find these counters talked about
consistently in terms of "consumption":

https://lore.kernel.org/linux-mm/20151214153037.GB4339@xxxxxxxxxxxxxx/

  I guess this was the reason why this approach hasn't been chosen before
  but I think we can come up with a way to stop the run away consumption
  even when the swap is accounted separately.

https://lore.kernel.org/linux-mm/20151215145011.GA20355@xxxxxxxxxxx/

  Allowing the parent to exceed swap with separate counters makes even
  less sense, because every page swapped out frees up a page of memory
  that the child can reuse. For every swap page that exceeds the limit,
  the child gets a free memory page! The child doesn't even have to
  cause swapin, it can just steal whatever the parent tried to free up,
  and meanwhile its combined memory & swap footprint explodes.

https://lore.kernel.org/linux-mm/20151215202235.GB15672@xxxxxxxxxxx/

  As far as the high limit goes, its job is to contain cache growth and
  throttle applications during somewhat higher-than-expected consumption
  peaks; not to contain "large unreclaimable high limit excess" from
  buggy or malicious applications, that's what the hard limit is for.

https://lore.kernel.org/linux-mm/5670E147.8060203@xxxxxxxxxxxxxx/

  The point is, at least for their customer, the swap is "resource",
  which should be under control. With their use case, memory usage
  and swap usage has the same meaning.


Now, with vswap - zswap becomes detached entirely from disk swap.

There's no (physical) swap slot being "reserved" by the zswap slot
usage and the slot is now just another chunk of memory. It is correct,
according to the definitions, to stop counting it in memory.swap.

Without detatching zswap from swap, this would be blatant breakage.

But, putting aside correctness, lets discuss usage of memory.swap as
an SLO signal, and whether this use case has merit.

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

Then let Chris make and defend a proposal for memory.pswap.* and
justify the redefinition of memory.swap to mean the total virtual
memory space eligible to be swapped.

If memory.swap has existed with dual meaning for long enough that users
depend on it to mean something other than the historical and documented
meaning - we should have this discussion.

That doesn't mean we should simply accept the redefinition, but the
proposal has some merit considering some ambiguity dating back 10 years.


I would like to know more about his use case and why it cannot be
accomplished by memory.low/min. I can see there being limitations to
those interfaces that need to be addressed, and maybe such a change to
the definition is warranted and a new interface needs to grow out of it.

This would also allow vswap=on or =off to work regardless of deployment.


Chris has done none of this - he has offered no solution or constructive
discussion. At best what Chris is doing is finding creative ways to say
"No" without engaging good faith discourse.

You'll notice Chris did not engage in the discussion around the
proposal which intended to solve his concerns

https://lore.kernel.org/linux-mm/CACePvbXb1WLz=OAAzVawf3oc3+dE3Z7qfPdagQ2dYuf3OALc2g@xxxxxxxxxxxxxx/

He asked no questions, he brought up a completely unrelated idea,
demanded justification for the unrelated idea, and then entirely
disengaged. He continues to demand workload numbers completely
detached from the discussion at hand, and makes dictations about what
an "appropriate amount" of compressed memory is.

He's more interested in fillibustering than finding a way forward,
and this behavior is quite innapropriate.

~Gregory