The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Baoquan He <baoquan.he@linux.dev>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, chrisl@kernel.org, kasong@tencent.com,
	shikemeng@huaweicloud.com, nphamcs@gmail.com, baohua@kernel.org,
	youngjun.park@lge.com, hannes@cmpxchg.org, yosry@kernel.org,
	chengming.zhou@linux.dev, linux-kernel@vger.kernel.org,
	Baoquan He <baoquan.he@linux.dev>
Subject: [RFC PATCH 00/10] mm/swap: ghost swapfile with backend switching via Redirect entries
Date: Tue,  7 Jul 2026 16:26:02 +0800	[thread overview]
Message-ID: <20260707082614.95030-1-baoquan.he@linux.dev> (raw)

This series introduces a virtual "ghost" swapfile that can be backed
by multiple physical swap devices, switching between them at runtime
using a new "Redirect" swap table entry type.

Motivation
----------
Physical swap devices have fixed, large sizes but a machine may only
need a fraction at any given time.  Ghost swap decouples the logical
swap capacity from physical swap allocation: it presents a large
virtual swap device to userspace while lazily mapping slots to
physical devices only when data must leave zswap (writeback).  This
enables overcommit of swap capacity without wasting physical disk
space, and allows the ghost device to grow dynamically at runtime.

Ghost swapfile characteristics
--------------------------------
Ghost swap decouples logical swap capacity from physical swap allocation.
Key properties:

- No backing store required.  A ghost swap device can operate purely
  as a zswap container — compressed pages stay in the zswap pool without
  ever touching a physical swap device.  No physical swap device needs
  to be attached.

- Optional physical backing.  One or more physical swap devices can be
  swapon'd alongside the ghost device, acting as writeback targets when
  the zswap pool needs to evict cold pages.  The Redirect entry in the
  ghost swap table links each evicted slot to its physical destination.

- Dynamic size growth.  The ghost device can be extended at runtime via
  sysfs, up to a current maximum of 1TB.  This is implemented through
  lazy vmalloc: a sparse 64MB virtual address space is reserved at
  swapon time to cover the full 1TB range, but physical pages for
  cluster_info[] structures are allocated only on demand as the device
  grows.  The cluster_info pointer never changes, so all existing
  accessors (__swap_offset_to_cluster, cluster_index) work unchanged.

- sysfs control.  Each ghost device exposes attributes under
  /sys/kernel/mm/ghost_swap/ghost_<N>/:
    path (RO) — backing device name
    max  (RW) — current max pages; writing a larger value triggers
                swap_ghost_extend_max()

Design overview
---------------
A swap table slot can now hold a Redirect entry:

  Redirect: |----- physical swp_entry_t -----|101|

This stores a plain swp_entry_t pointing to a slot on a real (physical)
swap device.  The low 3-bit mark (0b101) distinguishes it from Pointer
(0b100), PFN (0b10), Shadow (0b1), and NULL (0) entries.

The lifecycle is:

1. swapon a ghost device — reserves sparse vmalloc area (64MB virtual)
   and physically backs only the initial range.  The device starts with
   no physical backing store: pages swapped out go to zswap, and zswap
   pool evictions go to any concurrently attached physical device.

2. zswap writeback from ghost: when the zswap pool needs to evict,
   zswap_writeback_ghost() allocates a physical slot from any real
   swap device, writes the data there, and plants a Redirect entry
   in the ghost's swap table pointing to the physical slot.

3. Swap-in from ghost: swap_read_folio() detects the ghost device
   (SWP_GHOST), resolves the Redirect to the physical swp_entry_t,
   and forwards the read I/O to the physical device.

4. When the swap cache folio is removed, the Redirect entry is restored
   from an xarray (redirect_xa) that persists the mapping, so
   subsequent reads still find the physical backing.

5. When the physical slot is freed, the ghost slot is also freed,
   cascading through swap_range_free().

Note:
------
Ghost swapfile is a proof of concept. Compared with the other patchset:
[RFC PATCH v2 0/7] mm, swap:  Virtual Swap Space (Swap Table Edition),
it explores a different approach to implementing virtual swap on top of
the existing swap table infrastructure, with a simpler implementation.
It builds on Chris Li's earlier ghost swapfile work and is currently
tentatively named "ghost swapfile" — alternative naming suggestions are
welcome. Ghost swapfile setup can also be integrated through modifications
to the swapon API and the swapon command in util-linux, for example:
swapon --ghost ghost_1:2G -p 5.

Baoquan He (9):
  mm/swap_table: add Redirect entry encoding for ghost swap backend
    switching
  mm/swap: add redirect_xa field and ghost redirect helper declarations
  mm/swapfile: implement ghost redirect helpers and free-path cascade
  mm/swap_state: restore Redirect entry when swap cache folio is removed
  mm/zswap: implement ghost-to-physical writeback for backend switching
  mm/page_io: forward ghost swap reads to physical device via Redirect
  mm/swapfile: manage ghost cluster_info via lazy vmalloc
  mm/swapfile: implement swap_ghost_extend_max() for dynamic growth
  mm/swapfile: add sysfs interface for ghost swap extension

Chris Li (1):
  mm: ghost swapfile support for zswap

 include/linux/swap.h |  10 +
 mm/page_io.c         |  51 +++-
 mm/swap.h            |  16 +-
 mm/swap_state.c      |  28 +++
 mm/swap_table.h      |  38 +++
 mm/swapfile.c        | 579 ++++++++++++++++++++++++++++++++++++++++---
 mm/zswap.c           |  98 +++++++-
 7 files changed, 772 insertions(+), 48 deletions(-)

-- 
2.54.0


             reply	other threads:[~2026-07-07  8:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  8:26 Baoquan He [this message]
2026-07-07  8:26 ` [RFC PATCH 01/10] mm: ghost swapfile support for zswap Baoquan He
2026-07-07  8:26 ` [RFC PATCH 02/10] mm/swap_table: add Redirect entry encoding for ghost swap backend switching Baoquan He
2026-07-07  8:26 ` [RFC PATCH 03/10] mm/swap: add redirect_xa field and ghost redirect helper declarations Baoquan He
2026-07-07  8:26 ` [RFC PATCH 04/10] mm/swapfile: implement ghost redirect helpers and free-path cascade Baoquan He
2026-07-07  8:26 ` [RFC PATCH 05/10] mm/swap_state: restore Redirect entry when swap cache folio is removed Baoquan He
2026-07-07  8:26 ` [RFC PATCH 06/10] mm/zswap: implement ghost-to-physical writeback for backend switching Baoquan He
2026-07-07  8:26 ` [RFC PATCH 07/10] mm/page_io: forward ghost swap reads to physical device via Redirect Baoquan He
2026-07-07  8:26 ` [RFC PATCH 08/10] mm/swapfile: manage ghost cluster_info via lazy vmalloc Baoquan He
2026-07-07  8:26 ` [RFC PATCH 09/10] mm/swapfile: implement swap_ghost_extend_max() for dynamic growth Baoquan He
2026-07-07 22:36   ` Nhat Pham
2026-07-07  8:26 ` [RFC PATCH 10/10] mm/swapfile: add sysfs interface for ghost swap extension Baoquan He
2026-07-07  8:56 ` [RFC PATCH 00/10] mm/swap: ghost swapfile with backend switching via Redirect entries Baoquan He
2026-07-07 21:23 ` Nhat Pham
2026-07-07 21:25   ` Nhat Pham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260707082614.95030-1-baoquan.he@linux.dev \
    --to=baoquan.he@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=yosry@kernel.org \
    --cc=youngjun.park@lge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox