Re: [RFC PATCH 00/10] mm/swap: ghost swapfile with backend switching via Redirect entries

[Nhat Pham]

On Wed, Jul 15, 2026 at 7:19 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
>
> On 07/15/26 at 07:21pm, Baoquan He wrote:
> > Hi Nhat,
> >
> > On 07/12/26 at 05:02pm, Nhat Pham wrote:
> > > On Thu, Jul 9, 2026 at 4:39 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
> > ...snip...
> >
> > Sorry, I won't reply to each comment individually. I'll just leave
> > a summary reply at the end.
> >
> > > > I think VSS goes beyond solving the "zswap without backing store"
> > > > problem — it is fundamentally an architectural restructuring of the
> > > > swap subsystem, with virtual swap as a first-class abstraction layered
> > > > above physical devices.  That is both its strength (comprehensive,
> > > > future-proof) and its trade-off (more invasive to existing paths).
> > > > I respect that.
> > > >
> > > > My goal with ghost swap is different: address the immediate pain point
> > > > with the smallest possible change to the existing infrastructure.  Both
> > > > approaches have value, and I hope the community discussion will help
> > > > identify the right balance.
> > >
> > > That's because I believe "zswap without backing store" just by itself
> > > is a bit narrow of a problem. It's certainly nice to fix, but it's
> > > more of a nuisance - you already have userspace hacks for it (as I
> > > mentioned above).
> > >
> > > The problem I'm trying to solve is to support:
> > >
> > > 1. Writeback.
> > >
> > > 2. Dynamicity.
> > >
> > > 3. Decoupled backends.
> > >
> > > all of which are motivated by real production issues, not some
> > > theoretical problems. I'm concerned that if we only focus on the third
> > > goal, we'll dig ourself into a hole that prevents us from solving 1
> > > and 2 efficiently down the line.
> > >
> > > >
> > > > Thank you again for the detailed review — it has already clarified
> > > > which parts of the design need more thought and documentation, and will
> > > > make the next version stronger.
> > >
> > > I really don't want to be antagonistic, but I hope you'd take the real
> > > production pains that we've had (and have tried to communicate in
> > > multiple mailing threads, across a timeline of almost 2 years at this
> > > point) seriously.
> > >
> > > Collaborations should go both ways. I've gone out of my way to try to
> > > address the concerns of various parties, from spending *multiple
> > > weeks* testing and investigating performance regression on zram
> > > backend (which my company does not use), to a rewrite/re-design of
> > > virtual swap to accommodate parties who wished to opt out of virtual
> > > swap for now.
> > >
> > > I hope you can extend the same good will to our needs :) I've included
> > > you (and other swap folks such as Chris and Kairui) in my cc-lists. If
> > > you have concerns, you could have commented. Instead, you decided to
> > > send a patch series, which is basically just the ghost swapfile, with
> > > a bit of afterthought to handle writeback and dynamicity, rather
> > > inefficiently (no dedicated per-CPU caching), and not even correctly
> > > (the lack of rmap means swapoff / swap-cache-only physical swap slot
> > > reclaim is broken).
> > >
> > > I respect you and Chris very much to assume bad faith, but please work
> > > with me rather than against me.
> >
> > Before I get into the technical discussion, I want to address something
> > you raised at the end of your reply — the concern that I'm working
> > against you rather than with you. Our paths in MM simply haven't crossed
> > much until now. I can't think of reason why I would want to target you
> > or your work.
> >
> > I respect the work you've put into VSS. I did check it. Honestly I am not
> > fan of it. In your v2: 2244 insertions, 250 deletions, 15 files touched,
> > a new 455-line header (vswap.h). While swap subsystem has just absorbed the
> > swap table series. Then another 2200 lines of architectural restructuring
> > on top is added. Not sure if anybody raise concern about your solution,
> > or anybody suggests other directions.

Yes, it's a big patch series. But as you pointed out earlier, it
solves a larger problem with a single coherent design :)

> >
> > I posted ghost swap because I saw a concrete, narrow problem that I believed
> > could be solved with a small change. It makes decoupling and dynamic
> > growth with the minimum possible mechanism.  Writeback is explicitly deferred
> >  — not because it's unimportant, but because it's a separate problem that
> > shouldn't block the common case. With my shallow knowledge, it's optimal
> > solution to the encountered problem. If you agree, you can change to

The problem is not the lack of writeback support per se. I understand
that sometimes pieces of a design can be deferred to a follow-up patch
series.

I'm more concerned that the ghost direction so far does not seriously
take it into account in the design at all, which might make it either
impossible or very hard to redesign around down the line. I don't want
to rip a huge chunk of it out down the line later - we just avoided it
with the swap table with Kairui's proposal.

>
> Part of above sentence is missing. I meant if you agree on the ghost
> solution, you can change to take its way and continue, just add me to
> CC. Or we can work together.

How about this - let's solve one piece of the puzzle together, one at a time.

First, your optimization patch series. Have you taken a look at my
proposal ([1])? I believe that design should be cleaner, while still
allowing you to put it all you want to get (elimination of xarray
being the chief benefit), without requiring you to modify swap cache
and swap count operations (since you don't have to move the metadata
in and out of struct zswap_entry). It does require a bit more code to
dynamically allocated the backend array, but should be trivial IMHO.

[1]: https://lore.kernel.org/all/CAKEwX=OvR7GbU_9f2h_MtU4m0g6s-esHmNQKYNhJz610M0P3Sw@xxxxxxxxxxxxxx/

Next, if you just want pure ghost swapfile without writeback support,
maybe something similar to the first 2 patches in my RFC? i.e up to
this patch:

https://lore.kernel.org/all/20260612193738.2183968-3-nphamcs@xxxxxxxxx/

I'm sure you could find issues/bugs in it too with some extensive
testing (a lot of my performance testing is done on the entire series
as a whole), but from a design point of view it should achieve what us
both want, no? It's literally just a ghost swap device - most of the
other design elements of vswap (the new charging behavior, rmap,
support for writeback) comes in latter patches. I think the difference
is:

1. It's transparently dynamic, whereas in your RFC it's driven by a
userspace knob. Do you think there are inherent values in a userspace
knob?

2. The address space can also shrink when swap usage drops at runtime.

3. The dynamic address space is backed by an xarray. Note that it's
structured differently than zswap's one (it's an xarray pointing to
clusters). If you have rationales or numbers to show that vmalloc
array is superior (while still support the kernel-driven expansion and
shrink), please let me know.

If you have no faith in me and do not like my code, you can take the
code as a starting point, or just the idea, and drive it yourself. Or
let me know if you're unhappy with any piece of it - we can discuss
further.

>
> > Otherwise, please continue to push virtual swap forward. I'll stop and
> > wait.

Look man, I care about the problems being solved and I'm a sucker for
good ideas, but I'm not married to anything, be it my code or my
ideas.

I have literally dropped my old code and adopted Kairui's suggestions
after playing with it and liking it, to make sure every party's
concern is met.

If you have concerns, please let me know, or keep sending code if you
believe you can get it done better than I do :) All I'm asking is you
take my concerns into account in your design.