Re: Path forward for Virtualized Swap?

[Baoquan He <baoquan.he@linux.dev>]

On 09/10/26 at 09:39am, Shakeel Butt wrote:
> On Thu, Sep 10, 2026 at 03:09:59PM +0800, Baoquan He wrote:
> > Hi Nhat,
> > 
> > On 09/04/26 at 02:14pm, Nhat Pham wrote:
> > .....snip...
> 
> [...]
> 
> > With VM_SPARSE, xswap's cluster access is exactly the plain-array line the
> > rest of swap already uses:
> > 
> >     return &si->cluster_info[offset / SWAPFILE_CLUSTER];
> > 
> > no branch, no RCU discipline, no tear-down state machine, and no NULL
> > return. So VM_SPARSE doesn't add complexity to close a gap; it lets the
> > cluster layer stay as simple as it already is, which is precisely the
> > part later work (writeback, rmap lookup, memcg charging, THP) has to sit
> > on.
> > 
> > I'm not going to claim xswap wins on throughput. I measured it:
> > on a 64G/64-thread swapout, xswap, vswap and plain swap+zswap are all
> > within ~2-3% of each other, effectively identical. 
> 
> So the claim is VM_SPARSE is simpler than xarray based approach. I feel like
> we are discussing implementation details before deciding the design and
> architecture. So, instead of VM_SPARSE vs xarray, let's discuss and decide the
> need for dynamic growth. Why we want dynamic growth upfront or can it be added
> later? Once we decide that then it will be very easy to pick an implementation
> that would take us there.

Hi Shakeel,

Thank you for joining the discussion and for taking the time to comment.

Agreed on requirement first - but this one was already decided, and not by me. In
the July ghost swapfile thread Nhat rejected exactly the shape of "grow only, can
be added later":

    "Except for my virtual swap design, which does support dynamic growth AND
     shrinking of capacity on demand ;) If it cannot grow (and furthermore, if it
     requires userspace operation to trigger swapfile growth), why do we need this
     at all? Might as well create a new swapfile with swapon?"

To me what it converged on was "dynamic growth and shrink, no writeback yet".
So automatic growth *and* shrink is the requirement, and the simpler alternative
was already on the table.

And I keep mentioning it in the cover-letter of each version of my posting. I
only did the foundtation via lazy vmalloc. And Nhat will do the core
part including writabck, rmap lookup, memcg accounting, zero page fill,
etc.

What is still genuinely open, and I would like us to settle, is how large the
device's address space should be, because the metadata scales with it:

    address space = machine memory (128G)  ->  65536 clusters  ->  ~4MB table
    address space = worst case, like (8PB)->  ~4M clusters    ->  ~256MB table

Once that is fixed, choosing the lazy representation is a normal implementation
question - and it is the same question Johannes is asking from the other side.

As you can see, xswap make swap_cluster_info[] kept as is. Accessing it
is simple and easy, and the xswap code is not intrusive into normal swap
code, and won't add complexity to normal swap. Even though Nhat doesn't
admit it, saying if writeback is done on top of xswap, the code is messy
too. In fact, it's not. I have done a draft writeback part, I will post
for checking, there won't be a lot of struct swap_cluster_info_dynamic , 
swap_is_vswap() flying around.

Thanks
Baoquan