Re: Path forward for Virtualized Swap?

[Rik van Riel <riel@surriel.com>]

On Sun, 2026-09-27 at 06:17 -1000, Chris Li wrote:
> On Sun, Sep 27, 2026 at 2:29 AM Rik van Riel <riel@surriel.com>
> wrote:
> > 
> > On Sat, 2026-09-26 at 20:23 -1000, Chris Li wrote:
> > > 
> > > That is the part I am not sure I understand correctly. Fair in
> > > what
> > > sense? Using the swap file proportional to the memory limit of
> > > the
> > > cgroup? Do you have an example of perfectly fair swap file usage
> > > for
> > > a
> > > cgroup with an 8G memory limit versus one with a 1G limit?
> > > 
> > > Sorry I am a bit slow grasping what exactly the fair behavior is.
> > 
> > Say we have a 64GB swap file, and several
> > cgroups on the system, applications A & B,
> > and system.slice.
> > 
> > We might give system.slice a 10GB memory.swap.max,
> > and each application a 25GB memory.swap.max.
> > 
> > This way a memory leak in application B
> > does not result in application A being
> > unable to run.
> 
> Thanks for the explanation. To me, this is just standard
> memory.swap.max limit behavior. I was thinking there was some new
> concept of the fairness I haven't grasp..Thanks for the 
> clarification
> anyway.
> 
The only real change we are looking for is
that once zswap no longer automatically takes
up real swap space, the zswap use is no longer
counted under memory.swap.max

Only the data written out from zswap to
physical swap would count toward memory.swap.max.

That way both of the fixed size resources are
counted according to their own limits:
- memory.swap.max limits physical swap use
- memory.max limits anon + file + slab + zswap

-- 
All Rights Reversed.