Re: [RFC PATCH 0/7] mm: store zswap entries in swap table (Pointer entry)

[Nhat Pham]

On Tue, Jul 7, 2026 at 12:49 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Tue, Jul 7, 2026 at 12:28 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > On Tue, Jul 7, 2026 at 12:32 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
> > >
> > > Currently zswap uses a per-swap-device xarray to map swap offsets to
> > > zswap_entry pointers. This introduces an additional tree walk on every
> > > zswap entry access.
> > >
> > > This series replaces the xarray with a "Pointer" entry type stored
> > > directly in the swap cluster table. The new swp_tb_t variant embeds
> > > a zswap_entry pointer plus a entry count, eliminating the xarray and
> > > its lookup overhead entirely.
> > >
> >
> > Have you had the chance to review the virtual swap work (latest
> > version in [1])? At a first glance, it bears a lot of similarity to
> > this.
> >
> > We're envisioning this to be the future architecture for zswap :) Is
> > there anything that is missing that would satisfy your use case too?
> >
> > [1]: https://lore.kernel.org/all/20260612193738.2183968-1-nphamcs@xxxxxxxxx/
>
> Yeah this doubles down on the dependency of zswap on a swapfile being
> present, but I guess the goal is for this to be complimented by your
> other series to add ghost swapfile support. This was discussed at
> length, and we don't really want to have a user-facing ghost/virtual
> swapfile concept, at least not for now. Nhat's latest proposal is
> essentially a ghost/virtual swapfile implementation that is
> transparent to userspace, AFAICT.
>
> As Nhat mentioned, if there are deficiencies in his proposal that are
> addressed by yours, I think the most productive way forward is to
> start a discussion (here or on Nhat's proposal) to figure out the best
> way forward for everyone.

Now that I have taken another look at the other series too, I realized
that these 2 are really a big patch series, split into two. Vswap also
merges the zswap tree into the swap table infrastructure, and the code
paths are actually *simpler*: a lot of the swap-cache/swap refcounting
logic remains unchanged, whether the swap entry mapped to PTE belongs
to a virtual or physical swapfile.

With this new design:

1. Metadata can now live in struct zswap entry, if the swapfile is
zswap ghost swapfile.

2. You need to move the metadata around if you need to do zswap writeback.

It seems rather misleading to claim that the ghost zswap swapfile
design is simpler, when a lot of the complexity involved in this layer
merging is hidden in this optimization patch series.

If you're concerned about the xarray overhead, I'm willing to consider
the vmalloc array data structure. You can then graft the other
optimization in this series on to the vswap work.