Re: Path forward for Virtualized Swap?

[Gregory Price <gourry@gourry.net>]

On Mon, Sep 21, 2026 at 11:27:53AM -0400, Rik van Riel wrote:
> On Mon, 2026-09-21 at 09:27 -0400, Gregory Price wrote:
> > 
> > In short:
> > 
> >   memory.swap   = logical swap       - workload/SLO limit
> >   memory.pswap  = physical swap      - storage limit
> >   memory.zswap  = compressed memory  - RAM limit
> > 
> > This would preserve the existing memory.swap semantics while allowing
> > both backing resources to be constrained independently.
> > 
> My first thought was "this is confusing", but
> after a minute I realized that most users will 
> never set those options to anything other than 
> "0" or "max", and the few who do only need to
> touch one of them.
> 

In practice, at most two (zswap + pswap) with swap=max.

There's not much of a reason to set swap to anything other
than max if you already have zswap and pswap limits.

But for existing users where they're using it as an SLO
signal, they could continue getting the existing behavior
by just using swap.max.

That said:

I'm not convinced this is actually required, because the swap
counter was never an SLO mechanism - it is a physical swap
provisioning mechanism.  If it's being used as an SLO mechanism,
those users have misinterpreted its documented meaning.

memory.min / memory.low already provide you this logical limit
mechanism - so I would argue the parties that want such a split
(rather than treating zswap / swap *as* the split) need to prove
their use case cannot be supported by existing counters.

~Gregory