Re: Path forward for Virtualized Swap?

[Johannes Weiner <hannes@cmpxchg.org>]

Suren, if you've not been following this, there is a question you
might be best equipped to answer below.

On Thu, Oct 15, 2026 at 01:17:21AM +0800, Kairui Song wrote:
> On Tue, Oct 13, 2026 at 1:27 PM Chris Li <chrisl@kernel.org> wrote:
> > I understand that you have some face-to-face discussions at the
> > conference. Do we have a list of what has been aligned and what is
> > pending to discuss? We should have an agenda to avoid repeating
> > already aligned items.
> 
> Right, from my perspective, here are the following key points we can
> discuss further in the incoming meeting (most of them are not fully
> concluded yet):
> 
> 1. A limitation for the logical size: from my side, there are real
> usages for a global non-memcg limitation of the non-physical swap
> space: e.g. thin VMs as containers/pods with no cgroup limitations
> inside but which need in-VM memory compression and a proper limitation
> to avoid thrashing; or low-end devices/desktops that want global
> (root) limitations. And also, Android have a limitation on the ZRAM
> size (well for this one I'm not from Android team though so that's
> just my personal development experience with Android, enlarging the
> ZRAM size on several Phone swill cause serious junky of Apps due to
> over compression).

Android monitors psi to kill on excessive pressure. This should
capture thrashing from over compression.

Suren is CC'd, we should get his opinion.

> Nhat is concerned that exposing the sizing allows users to tune it and
> potentially misconfigure the system. However, I think a user with root
> permission should be fully aware of what they are doing or they can
> easily mess up the system in many ways and swap limitation is a very
> minor concern to me.
> 
> I think the requirement for a logical non-cgroup limitation is strong,
> but the discussion hasn't concluded on the implementation method.
> Perhaps something like a Kconfig combined with an interface or command
> line? More ideas are welcome.

I agree that overcommit control can be useful. But there are setups
that implement pressure-based policies and do utilization monitoring
just fine from userspace; they have no need for logical overcommit
bounds inside the kernel itself. *Defaulting* to a static limit and/or
making a choice mandatory seems like a mistake to me. It would make
more sense to treat this as a related but separate problem.

I'm happy to brainstorm solutions. But we should be open to discussing
this from scratch - userspace monitoring; an extension of
/proc/sys/vm/overcommit_* etc.

> 2. Charging: If you consider memory.swap is physical only then indeed
> we should not charge it, however, user are already doing that for
> years so this is a behavior change and we are also pushing memsw into
> memcgv2 as a interface to limit the logical memory usage of a
> container. So charging of the logical space is useful, how to handle
> that is tricky though.
> 
> From our usage, this should at least not block adding memsw or
> anything similar for memcgv2, even if you want more customized cgroup
> accounting, we need to charge it into some counter (a page counter,
> not just a statistic) in some way.

A path for memsw in cgroup2 is generally unlikely, actually. It was
intentionally split into separate memory and swap counters and not
forward-ported as a combined control.

Like I said, we should discuss overcommit control from scratch as an
orthogonal issue. I'm happy to do this and help find a solution. But I
want to get out of repeating that this is not compatible with cgroup2.

> 3. Swapoff: This was discussed again too, as vswap was trying to
> remove it. I think the concern is mostly about maintenance,
> performance, and practicality. From my perspective it's a critical
> component both for preventing minor or major faults before predictable
> high traffic arrives, or for operations/debugging, and for releasing
> the swap metadata to rule out any potential swap / page fault effect.
> There are concerns about maintenance or suggestions to use MADV, while
> I'll be happy to explore and improve the current in-kernel
> implementation of swapoff later if needed but removing it is a really
> bad idea in my view.

Here too I think we should be open about discussing the problem and
what a solution could look like.

"Swapoff" seems to presume the virtual space in the shape of a
manageable swapfile through standard interfaces.

A separate knob to clear out the vswap space would accomplish the same
functionality without pulling in the entire swapfile interface e.g.

> 4. Writeback: No doubt we all agree that we definitely should have
> writeback support, Nhat's concern is that we should handle the case
> where some cgroup doesn't need zswap/compression and ensure that works
> well.

+1

> 5. Interface: Given the issues above, what should the interface look
> like (swapfile, sysfs, /proc, etc.) and how should multiple
> (non-physical) swapfiles be used? Nothing much is discussed about this
> part though. I've heard users mention the use case of multiple
> compression swap spaces, but I don't have a use case for that myself,
> so I don't have many comments.

+1

It would be good to collect usecases first. Interfaces are forever and
we shouldn't add them on speculation.

> 6. The one part that I think we can and should agree on it shat the
> implement approach: at this point I think VM_SPARSE is the right
> direction, Nhat is concerned about the testing on it, and I think we
> can have more data for that, and collabration is highly encouraged. I
> previously conducted many tests on everything posted from both sides,
> will try to post more on this too.

Here I think we're actually least aligned.

The VM_SPARSE implementation requires a static size, and prior
discussion has made it clear that we actually have no consensus on how
to pick reasonable values - be it in the kernel or in userspace.

The xarray proposal requires none of these choices or interfaces, and
nobody has been able to show that it's actually a performance concern.