Re: [PATCH v5 01/11] mm, swap: add virtual swap device infrastructure

[Chris Li]

On Fri, Sep 25, 2026 at 8:25 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Thu, Sep 24, 2026 at 6:17 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
> >
> > On Thu, Sep 24, 2026 at 8:13 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
> >
> > Yes, but it will pay the price for going through the unnecessary
> > redirection layer always. It incurs performance and meta data
> > overhead. That was one of my previous objections to the earlier vswap
> > version. Sorry I enjoy micro optimization too much, that is both my
> > strength and weakness.
> >
> > >
> > > When everything in vswap, we don't need to test for it.
> > >
> > I've been there and done that, the result was pretty bad in those
> > earlier series.
> >
> > > Handling the details of what's behind the vswap would
> > > be handled one layer down.
> > >
> > > Chris, do you think that would be cleaner?
> >
> > If it can wrap below the swap_ops, it is just priviate inernal dedail
> > of implementing its own indirections. That would be much cleaner. That
> > is what I am trying to pitch to Nhat in prevoius email but does not
> > have following actions.
>
> Registering vswap's operation as into swap_ops isn't too hard. I
> frankly don't see much wins to it for vswap itself, but it's not hard
> to do if you like it.

I am offering these as ways to move forward with vswap. There is
always the alternaive to use xswap instead.

>
> What I'm disagreeing is treating it as "just another swap device". The
> implementation shares a lot of swap device's machinery, so I have
> don't mind adopting it, but you can't treat it like a normal swap
> device, and expose it to userspace like one. You get issues with
> allocations internally, and externally you give userspace a vector to
> misconfigure with device priority.

I'd like to hear more about this. If a user wants to shoot themselves
in the foot. My philosophy is just let them. It is not worthwhile to
complicate the code path. We can add a big fat warning that
"Oh, you are configuring xswap with a priority other than the
recommended one." But if the user really wants to do it, we should
allow it.

Another use case is when users employ more than one swap device to
reduce swap device lock contention. It is not a big deal when you swap
out a few GB of memory. But if you swap out more than 100G of memory,
the swap device lock contention really shows up in the earlier version
of the swap core. The new swap allocator and swap table significantly
reduce that contention. But that contention still exists. A few
hundred G of memory under one lock is just a bit too much. I think
there is a legitimate reason to use more than one device to reduce
lock contention.

Granted, other ways exist to reduce lock contention, but they increase
code complexity as well. The current swap device design is a good
balance of code complexity and flexibility.

> That's why I've been insisting on what's the use case that motivates
> these aspects of the interface that you're interested in. A pretty
> design is not a real usecase, especially one that creates problems
> with userspace misconfigurations.

Points taken; this isn't enough to justify the extra maintenance and
complexity of vswap right now. A cleaner alternative exists with less
complexity overhead.

Chris