Re: Path forward for Virtualized Swap?

[Kairui Song]

On Sat, Oct 24, 2026 at 4:03 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Fri, 2026-10-23 at 10:24 -0700, Nhat Pham wrote:
> >
> > * Swapoff: this was brought up as a request, but we ran out of time
> > before we could discuss the motivations and use cases behind them.
> > Folks interested, could you explain as a follow-up?
>
> This is one that I really don't understand.
>
> In my mind, we have vswap sitting as kind
> of a swap VFS between the rest of the system
> and the swap devices:
>
> +-------+     +------------+
> | vswap |-----| swap cache |
> +---+---+     +------------+
>     |
>     +----------+-----------+
>     |          |           |
> +---+---+  +---+---+   +---+---+
> | swap  |  | zswap |   | zram  |
> | file  |  |       |   |       |
> +-------+  +-------+   +-------+
>
> When a page is unmapped from userspace by the
> reclaim code, it goes into the swap cache.
>
> The vswap layer then decides where to store it
> at eviction time. This is configurable by userspace.
>
> If the zswap pool is shrunk, the vswap layer knows
> where to put the data next. There is no need to
> change page table entries to indicate that the
> data was moved from zswap to a swap file.
>
> If we decide to disable one of the backing swap
> devices, the vswap layer can just move the data
> into the swap cache, and the page reclaim code
> can evict it into a different backing store, if
> needed.

And in this case we want to disable vswap itself.

> Using vswap as a swap VFS would also allow us to
> get rid of the page table and tmpfs scanning
> code we have in swapoff today.
>
> In that model, I really do not understand what
> "swapoff vswap" means.

...

> What exactly do people want to accomplish here?

One thing is, to prevent page fault (minor), not sure if everyone is
aware, but a page fault itself is sometimes slower than swap IO /
compression (especially for compressed swap backend).

There are suggestions to use MADV from userspace, which is not really
maintainable when you have thousands of different, opaque and dynamic
workload, and that is very common for cloud providers.

I also hope there is a way to release swap metadata completely too.
e.g. for fs, you at least have umount, and can rmmod the fs itself
afterwards. We also have many ways to bypass the page cache. In cases
where a virtual layer is just a burden, we want raw physical swap, and
the ability to swap off that too.