Re: [PATCH 00/16] xswap: extendable swap device backed by zswap

[Nhat Pham]

On Tue, Sep 1, 2026 at 7:03 AM Baoquan He <baoquan.he@xxxxxxxxx> wrote:
>
> On 09/01/26 at 01:54am, Kairui Song wrote:
> > On Thu, Aug 27, 2026 at 05:44:50PM +0800, Baoquan He wrote:
> > > xswap is an extendable swap device with no backing storage. Swapped-out
> > > pages live only in zswap, so the device wastes no disk space and its
> > > size is independent of any physical device.
> > >
> > > xswap decouples PTE swap entries from physical backing storage. The
> > > cluster_info array is backed by a sparse vmalloc (VM_SPARSE) area that is
> > > grown and shrunk on demand:
> > >
> > > - Grow: when cluster allocation runs out of free clusters and the device
> > >   is below its ceiling, more physical pages are mapped into the VM_SPARSE
> > >   area and their clusters are added to the free list.
> > >
> > > - Shrink: when contiguous free clusters accumulate at the tail of the
> > >   mapped range (tracked in O(1) via nr_free_tail), they are unmapped and
> > >   the backing pages freed.  Shrink is deferred to a workqueue to avoid
> > >   lock recursion.
> > >
> >
> > Hi Baoquan,
> >
> > I didn't check too many details on how the implementation in previous
> > RFC until now, After looking at it, using VM_SPARSE to setup the cluster
> > info area is a really smart idea, really good job!
> >
> > I think many info are missing in the cover letter though so I wasn't
> > sure how this grow and shrink works from the description, after
> > checking the code, it looks much cleaner to me now, correct me
> > if I'm wrong:
> >
> > Every xswap device will have a huge and fixed "hard limit"
> > (si->max and si->nr_clusters_max), and practically can be considered
> > large enough to hold any workload, and won't change once swapon
> > is done.
> >
> > The actually data (si->cluster_info) of xswap device is completely
> > sparse and dynamic using VM_SPARSE, and so we don't need to change
> > any existing routine. It grow/alloc and shrink/free automatically by
> > the kernel, limited or driven by a "soft limit" (si->nr_clusters
> > and si->pages) which you can modify using the interface below.
>
> Thanks a lot for careful checking, and you are quite right about the
> mechanism and details.
>
> >
> > Once concern is that the "hard limit" is now the total RAM size. Isn't
> > that actually a bit small? Will be better if that one is tunable too?
> > With a parameter, and before swap on, as the hard limit is hard to
> > adjust once swapon is done. Any thing limiting this?
>
> Chris and I talked about this, we both think the total RAM size is a
> good hard limit. Because xswap is similar with zswap/zram in essence by
> compressing memory content to save memory. So the real limit is the
> zswap pool, not the slot count. In fact it's never able to utilize the
> total system RAM, right? Making it larger than system RAM is
> meaningless.

No. This is not quite right. The size of this device is the size of
the "swapped out" data, which is multiple times the post-compression
size (i.e zswap pool size). The multiple here depends on how well the
data is compressed.

This is not to consider the other swap backends:

1. zero-filled swap pages have effectively 0 memory footprint.

2. disk swap pages (I know this is not currently supported yet, but
it's a consideration for the overall design).

>
> Memory hotplug is a case in which system RAM can be enlarged during
> system running, while that can be taken into account later as a enhanced
> feature if it's really wanted.

A lot of these problems are self-inflicted. If we design a fully
dynamic swap device, then it's not in consideration.

>
> >
> > And I think these details better be mentioned bit more too.
>
> Sure, I can put these thoughts into cover letter or patch log for
> reference.
>
> >
> > > A per-device ceiling (nr_clusters) bounds growth and is adjustable at
> > > runtime via debugfs.
> > >
> > > Interface:
> > >
> > >   /sys/kernel/mm/xswap/create           write "<percent> [<prio>]" to
> > >                                         create a device; percent is a
> > >                                         percent of RAM (0 for the default),
> > >                                         prio is an optional swap priority
> > >                                         (default DEF_SWAP_PRIO)
> >
> > With what I have read so far, the mandatory percent limit here is kind of
> > strange, even with 0 as default. Why not make both args optional and just
> > let it grow without any limit by default? It looks more "fully dynamic"
> > that way.
>
> I'd like to clarify why we default to a soft limit rather than "no limit".
>
> The soft limit is the administrator's deliberate size choice, similar
> to how zram requires an explicit size. On a multi-TB system the
> cluster_info array is not free, so planning how much of it to allow is a
> real decision. The current behavior is: grow up to the soft limit as usage
> demands, then stay there. We do not shrink on idle, and shrink only happens
> when the admin lowers the limit. So there is no grow/shrink oscillation in
> normal operation.
>
> A default of "no limit / fully dynamic" will instead let the device grow
> without restriction under memory pressure. While allocating cluster_info
> pages exactly when memory is scarce, relying on shrink to reclaim afterwards,
> which is the oscillation we want to avoid. So we'll make both create arguments
> optional, but the default will be a sensible ceiling rather than unbounded.
>
> >
> > >   /sys/kernel/mm/xswap/destroy          write a swap type to tear down
> > >                                         a device
> > >   /sys/kernel/debug/xswap/type<N>_cluster_limit
> > >                                         read/write the per-device
> > >                                         cluster ceiling
> >

What's the point of having multiple xswap devices if it's going to be
dynamic, cluster-based anyway?