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

[Chris Li]

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.

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

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

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

Chris