Re: Path forward for Virtualized Swap?

[Kairui Song]

On Mon, Oct 26, 2026 at 11:59 PM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Sun, 2026-10-25 at 12:21 +0800, Kairui Song wrote:
> > Rik van Riel <riel@xxxxxxxxxxx> 于 2026年10月25日周日 02:16写道：
> > >
> > > On Sat, 2026-10-24 at 23:50 +0800, Kairui Song wrote:
> > > > On Sat, Oct 24, 2026 at 4:03 AM Rik van Riel <riel@xxxxxxxxxxx>
> > > > wrote:
> > > > >
> > > > > 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  |  |       |   |       |
> > > > > +-------+  +-------+   +-------+
> > > > >
> >
> > > However, having swapoff remove all data from the swap
> > > cache, after mapping the memory back into userspace
> > > page tables, seems like it would be fairly easy to do.
> > >
> > > Does that meet the needs of your use case?
> >
> > Right, it's nothing hard, as long as we don't add mandatory new
> > layers. For very high bandwidth swap devices, a mandatory indirection
> > layer is pure overhead.
>
> Don't we need a swap cache lookup regardless, to
> make sure the data we want to swap into the
> process is not already present in memory?
>
> At that point, it shouldn't matter whether we
> get the backing swap location from the swap
> cache lookup data structure, or from the
> page tables?
>
> We have the page table lookup, and the swap
> cache lookup. That is two lookups, regardless
> of whether there is indirection, or not.
>
> Am I missing something?

It involves more than just the swap cache. It includes book keeping in
cgroup accounting, statistics, allocation, device info reading, etc..
And swap cache is blazing fast nowadays so that isn't the problem
here.

We used to need to bypass the swap cache for similar reason, but we no
longer do that since the swap cache is flatten now:
https://lore.kernel.org/linux-mm/20251125-swap-table-p2-v3-7-33f54f707a5c@xxxxxxxxxxx/

Other parts I mentioned do not have zero overhead so keeping the layer
thin seems like the best approach.