Re: Path forward for Virtualized Swap?

[Chris Li]

On Sat, Sep 19, 2026 at 12:50 PM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Sat, 2026-09-19 at 11:21 -1000, Chris Li wrote:
> > On Sat, Sep 19, 2026 at 6:16 AM Rik van Riel <riel@xxxxxxxxxxx>
> > wrote:
> > >
> >
> > > However, I believe we do need to take care that
> > > whatever design we go with is actually able to
> > > support the end user functionality we want.
> >
> > Agree. I want to add that we should support new functionality without
> > sacrificing existing user functionality.
> >
> That means things need to work both for users
> who want to configure a zswap size, and for
> those who do not.

Sure, I don't think it needs a syscall like UAPI. But I do want a
kernel config for the power user who knows exactly what swap VMA limit
e.g., the % ratio to RAM or the ceiling—they need to use. The rest can
use MAX. VMA is a resource, I don't want unnecessary waste large
amount of VMA address. Other use cases legitimately require a large
VMA. So, power users should be able to set the limit if they know
exactly what they want.

> The cgroup memory.swap.max is an existing
> interface that does that on a per cgroup
> basis for swap, though in practice the
> limit mostly seems to be set to 0 (no swap),
> or to max (no limit).

Ack.

>
> memory.zswap.max does the same on the zswap
> side, again mostly 0 or max are used.

Ack

> Are you saying you rely on having something
> like that at the system level, too?

That is not what I have in mind. The example I have in mind is that
zswap is charged to swap counters. Changing that behavior will break
our current deployment and that of many other. Kairui give some
example as well. That behavior should not change.

Chris