Re: [PATCH v3 00/14] mm, swap: extendable swap devices (xswap)

[Baoquan He]

On 09/17/26 at 05:13pm, Nhat Pham wrote:
> On Wed, Sep 16, 2026 at 3:19 AM Baoquan He <hebaoquan@xxxxxxxxxx> wrote:
> >
> > xswap is a swap device with no backing storage. Swapped-out pages live
> > in zswap. Its cluster_info[] array lives in a VM_SPARSE vmalloc area,
> > and the area is grown and shrunk on demand as swap usage changes.
> >
> > The problem being solved is the static size of compressed swap. Both
> > zram and zswap need the size fixed in advance, and neither gives memory
> > back when the workload shrinks. The solution should be a device whose
> > size can scale up/down as per usage. xswap does that by mapping the
> > metadata lazily instead of reserving it for the whole range.
> >
> > Design
> > ------
> > - si->cluster_info[] stays a plain array. Access is still
> >   &si->cluster_info[offset / SWAPFILE_CLUSTER]: no per-access branch, no
> >   RCU discipline, no tear-down state machine, no NULL return.
> > - Only an initial chunk is mapped at creation. The rest of the address
> >   space is reserved, not allocated, so an idle device costs nothing.
> > - Growth is driven by allocation. When no free cluster is left and the
> >   address space has room, the next chunk is mapped and added to the free
> >   list. No userspace involvement.
> > - Shrink is driven by frees. The free tail is scanned, and whole chunks
> >   are unmapped once the mapped range is at most half in use and several
> >   chunks can go. One chunk is left mapped as slack, so the next
> >   allocation does not map it straight back. A ceiling lowered below the
> >   mapped range skips the half-in-use rule and is enforced at once.
> >
> > Size
> > ----
> > A device starts at 1xRAM, rounded down to the cluster. That costs
> > nothing, because the mapping is lazy. The underlying address space is
> > 2xRAM. An optional per-device cap,
> > /sys/kernel/mm/xswap/type<N>/limit, lets an admin lower the ceiling;
> > the excess is unmapped right away. Grow and shrink both work without
> > it. Creating a device requires zswap.
> >
> > Interface
> > ---------
> >   /sys/kernel/mm/xswap/create           write an optional priority
> >   /sys/kernel/mm/xswap/destroy          write a swap type
> >   /sys/kernel/mm/xswap/type<N>/limit    read/write, in pages
> > The device shows up in /proc/swaps as xswap<N>.
> >
> > Note
> > ----
> > Writeback, rmap lookup, etc. are consumers of this base. I have a
> > writeback prototype on top of this base and will post it as a reference.
> 
> Thanks for posting v3.
> 
> I spent a while building the other half of what I want out of this on
> top of your series, to see how much work is needed if we are to expand
> from xswap to cover the vswap use case.
> 
> It is actually way more work than I anticipated. And a lot of it is
> because of the way you indiscriminately apply the full swap device
> model to xswap, without careful consideration of actual use cases.

Don't worry, I have made a RFC to support xswap writeback, rmap, thp,
charging, etc. You can take it over and make it formal to post if you
decide to join to work together.