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

[Chris Li]

On Tue, Jul 21, 2026 at 11:37 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > 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.

But you still have one xarray for lookup swap entry to cluster right?

I want to get rid of xarray in both zswap and VS. The ultimate
solution is to not have xarray in the zswap/VS lookup of swap entries
at all. I believe achieving that would be a better win. I can already
see that happening by building on top of Baoquan's xswap kvmalloc
growth series.

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

I mean, here is my observation, please correct me if I am wrong,  VS
patche series needs two things from the swap core function:
1) able to allocate more swap entry beyond the current si->max.
Baoqun's kvmalloc grow patches should be able to answer that.
2) able to store private data structures per swap slot. e.g. a zswap
entry pointer, or a redirection pointer or both. We can modify the
swap core to provide this extra context per swap entry for each swap
device. In Baoquan's new purposal that is the vs_table array. We can
use the same kvmalloc grow trick to grow this pointer array as well.

That way, it does not need to have the VS xarray lookup in front of
cluster_info. You just keep growing the cluster info array and
vs_table array as needed.

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

Pending my deeper look into your patch series. I have been bitten by
your patch series' claim about metadata overhead before so I am a bit
more cautious about concluding anything regarding your patch's meta
data usage now :-)

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

It is not the case in my mind because the swap entry will require an
extra xarray lookup to get to the cluster info. No?
I do  not want that extra xarray lookup. I prefer an array lookup if
possible. With Baoquan's kvmalloc grow, that should be possible.

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

Yes, my concern is the xarray lookup for the swap cluster info.

> Can you clarify what you meant here? :)

It still has the xarray lookup in the code path (looking up the swap
entry index to get swap cluster info), that xarray is what I want to
get rid of.

Chris