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

[Nhat Pham]

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

Taking a step back from the ghost swapfile vs vswap debate - for this
optimization specifically, couldn't you adopt part of the vswap
design?

Specifically, expand the struct swap_cluster_struct to include the
virtual_table (feel free to rename it - but please make it generic,
like backend or sth, so that vswap can re-use it).

You can now do the rest of your optimizations exactly the same. No
need to add new swap table entry type. No need to juggle the swap
metadata between swap table and zswap entry's embedded field, which
means you don't have to change swap cache and swap reference counting
operations.

Now, yes, overhead is a problem indeed. But you can get around it by:

1. Guard the virtual_table array behind CONFIG_ZSWAP.

2. Make this array dynamically allocated. This is crucial, because
there will be setups where certain cgroups use zswap, and certain
cgroups use their own dedicated fast swapfile backends (via swap
tiers), and we do not want to burden the latter with zswap-induced
memory overhead. But should be trivial, and we can start with
something as simple as allocated on first zswap_store(), or during
swap allocation, if the folio's cgroup may zswap, etc.

Obviously, I'm biased, but I *think* this is actually simpler for your
optimization approach, no?