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

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

On 09/03/26 at 04:35pm, Youngjun Park 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.
> > 
> > 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)
> 
> As discussed before, until there's a per-memcg tier concept, is there
> a meaningful use case for having more than one xswap device? Would it
> make sense to limit it to a single device for now, and add support
> for multiple devices later once that structure exists?

Hi Youngjun,

Thanks for careful checking and your question.

Here, I am also confused why both you and Nhat oppose per-device xswap.
Actually, supporting per-device xswap was part of Chris's original plan
and was designed for the swap tier. From my perspective, it's also a
very natural thing because the current swap code natively supports
per-device, and swap tier needs to use it anyway, so I don't bother
to add code to restrict it to single device. More importantly, for
per-device xswap, you can use one if you want, or multiple if you want
too, it won't prevent anyone from using a single xswap instance.

> 
> Also, if xswap accepts an explicit prio, xswap devices would need to
> stay grouped within the same tier. But a slow tier with a different
> priority range could end up sandwiched in between, or an xswap device
> could fall outside the priority range needed to belong to the same
> tier.
> 
> Could prio just be fixed instead? Is there a reason it needs to be
> assignable per device?

A good question. I haven't thought of a good way for xswap prio. Fixed
prio, or a high prio region for xswap? Zram is ram swap device too, it
shares the same prio setting semantics as a normal one. Can we keep it
as is, to leave it to xswap user?

Thanks
Baoquan