Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Fri, Oct 23, 2026 at 2:52 PM Gregory Price (Meta) <gourry@xxxxxxxxxx> wrote:
>
> On 2026-10-23 13:25 -0700, Yosry Ahmed wrote:
> > On Fri, Oct 23, 2026 at 1:03 PM Rik van Riel <riel@xxxxxxxxxxx> wrote:
> > >
> > > +-------+     +------------+
> > > | vswap |-----| swap cache |
> > > +---+---+     +------------+
> > >     |
> > >     +----------+-----------+
> > >     |          |           |
> > > +---+---+  +---+---+   +---+---+
> > > | swap  |  | zswap |   | zram  |
> > > | file  |  |       |   |       |
> > > +-------+  +-------+   +-------+
> > >
> > > What exactly do people want to accomplish here?
> >
> > Today if you swapoff a swapfile, every is swapped in into the
> > swapcache, whether it's in zswap or on disk. With vswap, you have no
> > way to trigger swapin of compressed memory in zswap.
> >
>
> This seems like a missing interface in zswap, rather than something

Yeah, and I don't think implementing "draining" for zswap is terribly hard.

Zswap already has the reverse mapping (from zswap entry ->
virtual/physical swap slot). You can loop through zswap lrus, then for
each zswap entry, basically invoke the first half of
zswap_writeback_entry(), which loads the content into memory (i.e swap
cache).

But you're right - this is something that belongs to the backend
layer, not the virtual layer!

> vswap needs.  But you could just write this as
>
> vswap swapoff {
>   disable new backend writeback (swapcache fault-in only)
>
>   for each backend {
>     backend swapoff
>   }
> }
>
> so rather than vswap.swapoff() you'd actually just want a stop-bit that
> says to disable the swap subsystem writeback behavior to all backends.

Yeah if we can "swapoff"/"drain" each backend then that brings all the
content into memory!

>
> Otherwise the user can just disable each backend individually.
>
> --
> ~Gregory
>