Re: Path forward for Virtualized Swap?

[Rik van Riel]

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.

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.

We cannot umount the VFS.

What exactly do people want to accomplish here?

-- 
All Rights Reversed.