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

[Nhat Pham]

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.

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.

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.