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

[Youngjun Park <youngjun.park@lge.com>]

On Fri, Aug 07, 2026 at 05:11:05PM +0800, Baoquan He wrote:
> Hi Johannes,
> 
> On 08/05/26 at 10:17am, Johannes Weiner wrote:
> > On Wed, Aug 05, 2026 at 03:53:24PM +0800, Baoquan He wrote:
> > > From: Chris Li <chrisl@kernel.org>
> > > 
> > > 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.
> 
> Thanks for looking into this.
> 
> The file-based creation dance is there only because this is RFC —
> I wanted to reuse the existing swapon path so the core grow/shrink
> machinery could be measured and tested without also designing a new
> userspace interface. I agree it's not the right final interface.
> 
> The direction I'm thinking for the next revision:
> 
> - Drop the file requirement entirely.  An xswap device has no backing
>   store, so there is no reason it needs a file.
> 
> - Use totalram_pages as the initial per-device size.  Chris suggested
>   this, and it's a natural bound: if all anonymous memory is swapped
>   out, that is the maximum number of swap entries zswap will ever need,
>   assuming a reasonable compression ratio. The hard upper limit could
>   be 2 times of system RAM, or the max system RAM memory hotplug can
>   add to.
> 
>   Doing this because we need consider swap.tier support. A single global
>   xswap device in swap.tier would mean all memcgs compress into the
>   same device — there is only one swap entry namespace. With per-device
>   xswap instances, swap.tier can bind different memcgs to different xswap
>   devices, giving each its own swap slot namespace. Total isolation on slot
>   usage, no cross-memcg interference.

Hello Baoquan :)

Is there concrete user scenario isolation is needed?

>    -----
>    Hi Chris, Joungjun,
>    Please correct me if I misunderstood the swap.tier concept and xswap
>    use case in there.)

>    -----

Anysway, if we want to use xswap isolation like below,

	xswap t1  xswap t2     tier1     tier2
       | x1 |     | x2 |     | dev1 |  | dev2 |

then each memcg may have its own xswap front-end and backing tie

        memcg1: xswap t1  + tier1
        memcg2: xswap t2 + tier2

However, with the current tier design, the root cgroup needs to see the
whole tier layout. In that case, I think the root view may become unclear
if there are multiple xswap instances. From the root cgroup point of
view, it may be better to see xswap as one logical tier, not as two
separate tiers.

For example, the layout could be like this:

              xswap tier        tier1     tier2
        | xswap1 xswap2 |     | dev1 |  | dev2 |

Then each memcg can have its own mapping or policy:

        memcg1: xswap tier + tier1  (xswap1 + dev1)
        memcg2: xswap tier + tier2  (xswap2 + dev2)

With this model, the root cgroup can keep one simple global view of the
xswap tier. At the same time, each memcg can still use a specific xswap
area and a specific backing swap tier.

P.s I am thinking about multiple xswap usecase on tier. 
(this is just mind map. I don't know whether it is right or not)

Another possible layout may be to use xswap as a RAM buffer for each
tier

              tier1                 tier2
        | xswap + fast dev |   | xswap + slow dev |

We can use xswap as a simple buffering layer?
In that case, we would need a clear policy
for how xswap is assigned to each tier, and how the backing swap device is
selected for each tier. 

So why I am saying this is that, 
if xswap is managed as part of swap tiers, it would
be helpful to define a more concrete layout and policy for xswap
assignment.

This would make the isolation use case much clearer

Thanks!
Youngjun