Re: Path forward for Virtualized Swap?

[Gregory Price <gourry@gourry.net>]

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@gourry.net> 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).

~Gregory