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

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

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.
> 
> 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

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.


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