Re: Path forward for Virtualized Swap?

[Baoquan He]

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

Thanks
Baoquan