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

[Nhat Pham]

On Tue, Jul 21, 2026 at 11:24 AM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> On Thu, Jul 16, 2026 at 9:49 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > > > [1]: https://lore.kernel.org/all/CAKEwX=OvR7GbU_9f2h_MtU4m0g6s-esHmNQKYNhJz610M0P3Sw@xxxxxxxxxxxxxx/
> > >
> > > 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.
>
> Understand.
>
>
> > > 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
>
> We might need a clearer definition of negligible. e.g. in my mind less
> than 1 byte per 4K size swap slot.

I laid out the overhead below already :)

>
> > 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)!
>
> I hope you are not clinging to that xarray because I want to get rid
> of that as well.

That's what I meant though. The virtual table replaces it for vswap users.

>
> > 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.
>
> I also mean the normal path that accesses the swap table will take an
> xarray lookup with different locking requirements.
> I prefer to keep the swap table and cluster info where they are now to
> avoid that extra complexity in the mental model.
>
> It seems allowing the cluster array's virtual entry to grow should
> mostly answer your VS need?

I don't get it. What do you mean here?

>
> > 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?
>
> Regarding the memory size, yes, if the overhead is less than 1 byte
> per swap slot compared to the ghost swapfile. The location and lookup

If you see where I miss, point out. Otherwise I'll take that as a yes? ;)

> path for the swap table and cluster info are not ideal because VS will
> force a different location and lookup code path. I prefer growing the
> cluster info array to gain more swap entries and keep the current swap
> cluster and swap table data structures where they are.

The current swap cluster and swap table data structure are *exactly*
where they are. In fact my proposal keep it closer to the status quo -
once you lock the cluster, swap cache and swap count operations are
*exactly* the same, whereas Baoquan's approach requires taking swap
table information and shove it into the struct zswap entry.

Can you clarify what you meant here? :)