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

[Baoquan He <baoquan.he@linux.dev>]

On 07/16/26 at 09:49am, Nhat Pham wrote:
> On Wed, Jul 15, 2026 at 4:04 PM Chris Li <chrisl@kernel.org> wrote:
> >
> > On Wed, Jul 15, 2026 at 9:18 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > >
> > > On Wed, Jul 15, 2026 at 7:19 AM Baoquan He <baoquan.he@linux.dev> 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@linux.dev> 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@mail.gmail.com/
> >
> > Hi Nhat,
> >
> > Sorry for the late reply. I've been busy and just saw this.  First
> > impression looks promising, it is better than any previous version of
> > VS. Thanks for incorporating Kairui's feedback. Please give me some
> > time to sleep on it. I will get back to you on that.
> 
> Please take a look. I was waiting for your response as well :)
> 
> The patch series is large, yes, but it's an RFC meant to show case the
> final end design.
> 
> >
> > > 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@gmail.com/
> > >
> > > 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
> >
> > May I add one wishlist item related to ghost swapfile here? I will
> > reply to your VS thread for other feedback.
> >
> > For the ghost swapfile usage case (no writeback). Can VS support this
> > usage case while maintaining per-swap-slot metadata usage comparable
> > to the ghost swapfile implementation? If we have to put a number to
> > it, let's say the increase in metadata is less than 1 byte per swap
> > slot compared to the ghost swapfile implementation.
> >
> > We have large deployments of ghost swapfile in the fleet. I want an
> > upstream aligned solution that does not increase the existing memory
> > overhead compared to the current ghost swapfile deployment, for that
> > usage. As you know, memory pricing and optimization pressure are high.
> > The ghost swapfile patch itself is relatively simple. If VS can
> > address this usage case, it will remove a lot of incentive to explore
> > ghost swapfile-like solutions.
> 
> Hi Chris. I have some thoughts on this - let me know what you think.
> 
> I understand the memory overhead discussion here. In the case where
> vswap slot is backed by a real swapfile, I have not figured out a way
> to make the overhead disappear yet. The damn rmap is very annoying - I
> have some strategies to get around it for certain operations, but none
> of it can be done without a full fledged patch series of its own.
> 
> However, with the ghost zswap swapfile backend specifically, I think
> the overhead is going to be negligible compared to the status quo
> upstream (things might be different internally at Google - please let
> me know!). This is because the main remaining per-slot overhead comes
> in the form of one per-cluster array to store the "backend", here it's
> going to store struct zswap_entry pointers. This is not extra overhead
> though, because it basically replaces the xarray (that you added all
> those years ago)!
> 
> The rest is small stuff here and there that is not O(slot) but rather
> O(cluster). For example one struct rcu_head per cluster, xarray
> overhead for the dynamicization - note that this xarray manages
> cluster, not slot. I think that's all, unless I miss something.
> 
> So if you don't writeback, i.e no physical swapfile, then I think
> there is negligible overhead (no rmap and all that jazz).
> 
> Does this sound acceptable to you?
> 
> Baoquan, what do you think?

Thanks for the thoughtful reply and the very constructive proposal.
Your suggestion about moving forward in small, incremental steps in
last mail is really appealing — I think that's the right way to make
progress on this. I need a little time to think it through more
carefully before giving you a proper response. Will get back to you
soon.

Thanks
Baoquan