Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Wed, Oct 14, 2026 at 10:17 AM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
>
> 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.

Let's see if I can help by doing the rebase :) We can use vswap as the baseline.

And yeah, from a pure conceptual PoV, I'm ambivalent about VM_SPARSE.
I just think it needs more data, as it imposes design implications on
the rest of the implementation, whereas I already test vswap on a
couple of workloads, including real swap-heavy production workloads
with a mixed of swap and zswap users. Performance was good.

My question - and we can wait until the meeting to discuss - is why
are we insistence on dropping all of existing code to just switch to
VM_SPARSE? I would understand if it is indeed very difficult to switch
down the line, but I don't think it is, based on my past hacky
attempts to do it?

>
> That's a lot of problems already. I think we can discuss these points
> further in the meeting.

Thanks for the summary, Karui. From my end, these are my concerns:

1. Interface: I don't like interface without justification. It has
real userspace impact. Things like priority should not be exposed at
all.

And we should also avoid overloading swap interfaces with things other
interfaces are better suited to handle. For instance, while I
sympathize with your logical memory use cases, but I chatted with
Johannes, and he pointed out that the overcommitting interface is
better than swap for this purpose.

Idk - maybe expanding /proc/sys/vm/overcommit_memory?

2. Charging: personally I don't want virtual slots to charge to
physical swap space, but I won't speak for memcg maintainers. One
thing we can discuss is what kind of use case relies on the existing
charging behavior, and come up with alternative setups to handle these
use cases.

3. Make sure any solution supports setups with mixed backends (per-cpu
caching should also distinguish vswap v.s other swap solutions).

Once we have a better idea of the rough design, then we can talk about
implementations.

Things I think we can skip:

1. Writeback - this is a given now, I don't want to argue about it
anymore. Just include it please.

2. Swapoff - I don't think it should be a blocker in the first place.
Vswap does not expose that functionality to userspace, but exposing it
is trivial, because the machinery is identical to physical swapfile
swapoff. If you want it could be a small-ish follow up patch.

3. Memsw:  I think it's mostly a separate conversation. Vswap does not
block memsw. FWIW, right now I keep vswap charged to memsw in cgroupv1
because my understanding is that it's a logical counter, so it should
count a page regardless of the physical reality.

So if you expose memsw to cgroupv2, it will work as-is. The question
is whether memsw will exposed to v2 in the first place, and that's
orthogonal. Maybe the memcg folks can have a separate meeting to
discuss it?