Re: Path forward for Virtualized Swap?

[Chris Li]

On Tue, Sep 22, 2026 at 11:39 PM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
>
> On 09/21/26 at 01:02pm, Gregory Price wrote:
> > On Mon, Sep 21, 2026 at 06:32:56AM -1000, Chris Li wrote:
> > > On Mon, Sep 21, 2026 at 3:27 AM Gregory Price <gourry@xxxxxxxxxx> wrote:
> > > >
> > > > This would preserve the existing memory.swap semantics while allowing
> > > > both backing resources to be constrained independently.
> > >
> > > It sounds like you want memory.tiers have limit enforced.
> > >
> > > I suppose it is possible. Again I want to see how people would
> > > actually use this feature.
> > >
> >
> > Possible, but arguably not needed. the swap and zswap counters already
> > work for this existing interaction.
> >
> > As I pointed to in my response to Rik, in every reasonable use of
> > pswap+zswap the global swap counter is pointless.
> >
> > So then pswap=swap and we're left with zswap and swap.
> >
> > And I'm not convinced your reading of the swap counter as a limit on the
> > *logical* memory allowed to be swapped out is actually accurate.
> >
> >   memory.swap.current
> >         The total amount of swap currently being used by the cgroup
> >         and its descendants.
> >
> >   memory.swap.max
> >         Swap usage hard limit.  If a cgroup's swap usage reaches this
> >         limit, anonymous memory of the cgroup will not be swapped out.
> >
> > There is no documentation I can find that has ever documented these
> > counters as "the amount of memory requiring a fault".  If you put a
> > compression system in front of physical swap - the counters as-described
> > would still be accurate, while your reading would be broken.
> >
> > "swap" here is highly implied to mean "storage" as opposed to memory,
> > which is why "zswap" defines its limits in terms of memory.
> >
> >   memory.zswap.current
> >         The total amount of memory consumed by the zswap compression
> >         backend.
> >
> >   memory.zswap.max
> >         Zswap usage hard limit. If a cgroup's zswap pool reaches this
> >         limit, it will refuse to take any more stores before existing
> >         entries fault back in or are written out to disk.
> >
> > If you're presently using swap.max to mean the "logical amount of memory
> > allowed to be swapped" - then your usage does not meet the definition of
> > the knob.  You need to justify that your use case cannot be expressed
> > via memory.min/low controls:
> >
> >   memory.min
> >         Hard memory protection.  If the memory usage of a cgroup
> >         is within its effective min boundary, the cgroup's memory
> >         won't be reclaimed under any conditions. If there is no
> >         unprotected reclaimable memory available, OOM killer
> >         is invoked. Above the effective min boundary (or
> >         effective low boundary if it is higher), pages are reclaimed
> >         proportionally to the overage, reducing reclaim pressure for
> >         smaller overages.
> >
> > 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.

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.

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

Chris