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

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

On 09/16/26 at 12:45pm, Johannes Weiner wrote:
> On Wed, Sep 16, 2026 at 06:19:07PM +0800, Baoquan He 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.
> 
> If the swap maintainers prefer the VM_SPARSE route, I'm happy to defer
> to them on that.
> 
> However, from the cgroup and zswap camp, two stipulations that I
> reasoned out in the other thread[1]:

> 
> 1. You must not charge compression space as swap space to the cgroup.

Hmm, I don't have a stance on this. However, isn't this an issue
zswap/zram have been doing? It feels like an independent issue which
should be done separately?

> 
> 2. You must make the compression space large enough to be outside the
>    range where users can hit space limits before hitting memory limits.

We may need a way to define 'large enough' at first. From my limited
understanding, take zstd (the best compression ratio) as an exmaple,
the ratio is about 30%, 2xRAM as si->max is enough. Unless we want to
swap to the backing disk with huge content which is much much bigger
than RAM when xswap is ful. I am wondering if there is a actual scenario 
and concrete number.

I am not against a large enough si->max size, that's very easy to change
in code, just one line of adjustment. Just a concrete number and reasonable
description is needed. I think this can be done later with a separate
patch with a convincing log if someone can provide?

static int xswap_create(int prio)
{ 
	...
        ram = totalram_pages();
        maxpages = min_t(unsigned long, ram * 2, swapfile_maximum_size);
	...
}

> 
>    That also means not allowing setups where this is possible.

And the limit is only an optional knob. If the admin does not set it,
the device grows to the full address space, so there is no space limit
to hit at all. It already behaves the way you want by default. The knob
is only for admins who want a ceiling, they can use it or not. I hope
this would not be a problem for your use case.                                                  

> 
>    I'm fine with fixing the zeroed page flood issue separately, as
>    Kairui proposed.
> 
> So if you're willing to fix the cgroup charging, and if you're willing
> to drop the sizing interface for a statically sized space that is
> sufficiently large, I think we can find common ground.

Thanks for the input, I am open to discuss either of them further.

> 
> [1] https://lore.kernel.org/linux-mm/aqLi6cIjD2wJwk0B@cmpxchg.org/
>