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

[Baoquan He]

Hi Nhat,

On 07/15/26 at 09:17am, Nhat Pham wrote:
> On Wed, Jul 15, 2026 at 7:19 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
...snip...
> > Part of above sentence is missing. I meant if you agree on the ghost
> > solution, you can change to take its way and continue, just add me to
> > CC. Or we can work together.
> 
> How about this - let's solve one piece of the puzzle together, one at a time.

I took your suggestion to heart.  I've been working on the first piece:
dynamic cluster management for xswap (vswap) devices — the VM_SPARSE
vmalloc approach for growing and shrinking the cluster_info array on
demand.

The series is 10 patches (plus Chris's xswap base patch) and I just
posted it:

  https://lore.kernel.org/all/20260727135029.1059441-1-baoquan.he@xxxxxxxxx/

The idea is simple: instead of allocating the full cluster_info[] at
swapon, we back it with a VM_SPARSE vmalloc area that maps physical
pages lazily as clusters are allocated, and unmaps them from the tail
when enough contiguous free clusters accumulate.  Lookup stays O(1)
via array indexing — no extra xarray in the cluster access path.

Once the dynamic cluster management lands, you'd add the per-slot
backend pointer, writeback, and rmap on top — without changing the
cluster_info lookup path.

The shrink is coarser than what xarray could do (full pages at a time,
not individual clusters), but for the initial landing where swap usage
tends to be ratchet-like, I think this is a reasonable trade-off.  If
the need arises, we can always revisit the shrink granularity later.

Curious to hear what you think — especially whether this provides the
cluster management your VS series needs.

Thanks
Baoquan

> 
> First, your optimization patch series. Have you taken a look at my
> proposal ([1])? I believe that design should be cleaner, while still
> allowing you to put it all you want to get (elimination of xarray
> being the chief benefit), without requiring you to modify swap cache
> and swap count operations (since you don't have to move the metadata
> in and out of struct zswap_entry). It does require a bit more code to
> dynamically allocated the backend array, but should be trivial IMHO.
> 
> [1]: https://lore.kernel.org/all/CAKEwX=OvR7GbU_9f2h_MtU4m0g6s-esHmNQKYNhJz610M0P3Sw@xxxxxxxxxxxxxx/
> 
> Next, if you just want pure ghost swapfile without writeback support,
> maybe something similar to the first 2 patches in my RFC? i.e up to
> this patch:
> 
> https://lore.kernel.org/all/20260612193738.2183968-3-nphamcs@xxxxxxxxx/
> 
> I'm sure you could find issues/bugs in it too with some extensive
> testing (a lot of my performance testing is done on the entire series
> as a whole), but from a design point of view it should achieve what us
> both want, no? It's literally just a ghost swap device - most of the
> other design elements of vswap (the new charging behavior, rmap,
> support for writeback) comes in latter patches. I think the difference
> is:
> 
> 1. It's transparently dynamic, whereas in your RFC it's driven by a
> userspace knob. Do you think there are inherent values in a userspace
> knob?
> 
> 2. The address space can also shrink when swap usage drops at runtime.
> 
> 3. The dynamic address space is backed by an xarray. Note that it's
> structured differently than zswap's one (it's an xarray pointing to
> clusters). If you have rationales or numbers to show that vmalloc
> array is superior (while still support the kernel-driven expansion and
> shrink), please let me know.
> 
> If you have no faith in me and do not like my code, you can take the
> code as a starting point, or just the idea, and drive it yourself. Or
> let me know if you're unhappy with any piece of it - we can discuss
> further.
> 
> >
> > > Otherwise, please continue to push virtual swap forward. I'll stop and
> > > wait.
> 
> Look man, I care about the problems being solved and I'm a sucker for
> good ideas, but I'm not married to anything, be it my code or my
> ideas.
> 
> I have literally dropped my old code and adopted Kairui's suggestions
> after playing with it and liking it, to make sure every party's
> concern is met.
> 
> If you have concerns, please let me know, or keep sending code if you
> believe you can get it done better than I do :) All I'm asking is you
> take my concerns into account in your design.