Re: [RFC PATCH v2 0/7] mm, swap: Virtual Swap Space (Swap Table Edition)

[Yosry Ahmed]

On Sun, Jun 14, 2026 at 7:39 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Sun, Jun 14, 2026 at 4:20 AM YoungJun Park <youngjun.park@xxxxxxx> wrote:
> >
> > ...
> > > * Integration with swap.tier by Youngjun (see [12]). For now, I'm
> > >   leaning towards opting out the vswap device from swap.tier entirely, and
> > >   treat it as a special device. Integrating it with swap.tiers will
> > >   benefit the cases where you want some cgroups to skip vswap for fast
> > >   swap devices (pmem), whereas other should go through zswap first. But
> > >   most other use cases, either the overhead of vswap will be acceptable
> > >   (or not the bottleneck), or we can just disable CONFIG_VSWAP entirely :)
> > >
> > >   Youngjun, may I ask for your thoughts on this?
> >
> > Hi Nhat,
> >
> > Tier 1: VSWAP, Tier 2: ZSWAP ...
> >
> > I don't see any problem applying the desired functionality with the
> > currently proposed mechanism and interface. With this, a user would be
> > assigned the default Virtual -> RAM swap tier, and the overall picture
> > becomes one where swap tiers are composed according to the priority
> > setting.
>
> It's more - is there a strong argument to let vswap be a tier (which
> is not supported by just turning of vswap altogether).
>
> Because right now I'm not exposing vswap device to userspace in any
> manner, pretty much. It's abstract and transparent, and minimizes
> complexity (no vswap and swap.tier interaction) and surfaces for
> issues.

I definitely think vswap should *not* be a tier. First of all, a vswap
entry can be backed by zswap or an actual swap device, which would be
two different tiers. How does that work?

I also think vswap should not be exposed to userspace in any way, at
least not now. I still think we should aim to just make the
redirection layer always on and eliminate "vswap devices".