Re: [RFC PATCH v2 01/10] mm: xswap support for zswap

From: Johannes Weiner

Date: Wed Aug 05 2026 - 10:23:39 EST


On Wed, Aug 05, 2026 at 03:53:24PM +0800, Baoquan He wrote:
> From: Chris Li <chrisl@xxxxxxxxxx>
>
> Introduce extendable (virtual) swap device support ??? xswap.
>
> The current zswap requires a backing swapfile. The swap slot used
> by zswap is not able to be used by the swapfile, wasting swapfile
> space.
>
> An xswap device is a swapfile that only contains the swap header,
> with the header indicating the size of the virtual swap space. There
> is no swap data section, therefore no waste of swapfile space. Any
> write to an xswap device will fail. To prevent accidental read or
> write, bdev of swap_info_struct is set to NULL. Xswap devices set
> the SSD flag because there is no rotational disk access when using
> zswap.
>
> Zswap writeback is disabled if all swapfiles in the system are
> xswap devices (tracked via nr_real_swapfiles).
>
> How to create an xswap device:
> touch swap.1G
> truncate -s 1G swap.1G
> mkswap swap.1G
> dd if=swap.1G of=xswap.1G bs=4096 count=1
> # xswap.1G is 4K on disk but reports 1G capacity
> swapon xswap.1G

Sigh.

Why does the user have to go through this dance?

Why does the user have to decide in advance what size the space needs
to be?

You point out no inherent limit to how much can be compressed, so
there is no reason to make userspace decide on an arbitrary one.

There is no reason to tie an address space that can be managed
transparently inside the kernel to TWO named files on disk.

There are plenty of past discussions on this very topic. I don't see
the point in resubmitting the same thing under different names,
without even a reference to previous discussions.

As a side note: if you have to add "(virtual)" after every instance of
"extendable", then maybe "extendable" is a terrible name and you
should just call it "virtual".