Re: [PATCH RFC] mm: ghost swapfile support for zswap

[Nhat Pham <nphamcs@gmail.com>]

On Mon, Dec 1, 2025 at 10:32 PM Baoquan He <bhe@redhat.com> wrote:
>
> On 12/02/25 at 10:56am, Barry Song wrote:
> > On Sat, Nov 22, 2025 at 6:00 PM Kairui Song <ryncsn@gmail.com> wrote:
> > >
> > > On Fri, Nov 21, 2025 at 5:52 PM Chris Li <chrisl@kernel.org> wrote:
> > > >
> > > > The current zswap requires a backing swapfile. The swap slot used
> > > > by zswap is not able to be used by the swapfile. That waste swapfile
> > > > space.
> > > >
> > > > The ghost swapfile is a swapfile that only contains the swapfile header
> > > > for zswap. The swapfile header indicate the size of the swapfile. There
> > > > is no swap data section in the ghost swapfile, therefore, no waste of
> > > > swapfile space.  As such, any write to a ghost swapfile will fail. To
> > > > prevents accidental read or write of ghost swapfile, bdev of
> > > > swap_info_struct is set to NULL. Ghost swapfile will also set the SSD
> > > > flag because there is no rotation disk access when using zswap.
> > > >
> > > > The zswap write back has been disabled if all swapfiles in the system
> > > > are ghost swap files.
> > >
> > > Thanks for sharing this, I've been hearing about the ghost swapfile
> > > design for a long time, glad to see it finally got posted.
> > >
> > > >
> > > > Signed-off-by: Chris Li <chrisl@kernel.org>
> > > > ---
> > > >  include/linux/swap.h |  2 ++
> > > >  mm/page_io.c         | 18 +++++++++++++++---
> > > >  mm/swap.h            |  2 +-
> > > >  mm/swap_state.c      |  7 +++++++
> > > >  mm/swapfile.c        | 42 +++++++++++++++++++++++++++++++++++++-----
> > > >  mm/zswap.c           | 17 +++++++++++------
> > > >  6 files changed, 73 insertions(+), 15 deletions(-)
> > >
> > > In general I think this aligns quite well with what I had in mind and
> > > an idea that was mention during LSFMM this year (the 3rd one in the
> > > "Issues" part, it wasn't clearly described in the cover letter, more
> > > details in the slides):
> > > https://lore.kernel.org/all/CAMgjq7BvQ0ZXvyLGp2YP96+i+6COCBBJCYmjXHGBnfisCAb8VA@mail.gmail.com/
> > >
> > > The good part is that we will reuse everything we have with the
> > > current swap stack, and stay optional. Everything is a swap device, no
> > > special layers required. All other features will be available in a
> > > cleaner way.
> > >
> > > And /etc/fstab just works the same way for the ghost swapfile.
> >
> > Apologies — let me raise a question that may be annoying.
> > I understand that people may already be feeling tense and sensitive.
> >
> > Despite the benefit of compatibility with /etc/fstab, we still need to provide
> > a physical file on disk (or elsewhere), even if it contains only a header.
> > Personally, this feels a bit odd to me. Is it possible to avoid having a
> > “ghost” swap file altogether and instead implement all "ghost" functionality
> > entirely within the kernel? Ideally, we wouldn’t need to introduce a new
> > “ghost” concept to users at all.
> >
> > In short, we provide the functionality of a ghost swap file without actually
> > having any file or “ghost” at all.
>
> That's actually what I would like to see. Just to make that we may need
> change syscall swapon, to specify the flag to mark it and initial size.
> People may complain about adjustment in syscall swapon.

Yeah that's another design goal with virtual swap - minimizing the
operational overhead.

With my design/RFC, all you need to do is:

1. Enable zswap at the host level (/sys/module/zswap/parameters/enabled).

2. Enable zswap at the cgroup level, through memory.zswap.max (you can
also size per-cgroup zswap limit here, if you so choose).

and it *just works*. Out of the box. No need to create a new swapfile,
/etc/fstab, etc.

If you're unsure about your workload's actual zswap usage, you can
keep it unlimited too - it will just grows and shrinks with memory
usage dynamics.

One design for every host type and workload characteristics
(workingset, memory access patterns, memory compressibility).