Re: [PATCH v4 00/11] Virtual Swap Space (Swap Table Edition)

[Andrew Morton]

On Tue, 25 Aug 2026 08:32:26 -0700 Nhat Pham <nphamcs@xxxxxxxxx> wrote:

> Currently, when an anon page is swapped out, a slot in a backing swap
> device is allocated and stored in the page table entries that refer to
> the original page. This slot is also used as the "key" to find the
> swapped out content, as well as the index to swap data structures, such
> as the swap cache, or the swap cgroup mapping. Tying a swap entry to its
> backing slot in this way is performant and efficient when swap is purely
> just disk space, and swapoff is rare.
> 
> However, the advent of many swap optimizations has exposed major
> drawbacks of this design. The first problem is that we occupy a physical
> slot in the swap space, even for pages that are NEVER expected to hit
> the disk: pages compressed and stored in the zswap pool, zero-filled
> pages, or pages rejected by both of these optimizations when zswap
> writeback is disabled. This is arguably the central shortcoming of
> zswap:

Thanks.

I asked Gemini for a tl;dr and was told

: Introduce Virtual Swap Space (vswap) to decouple swap entry management
: from physical disk slots by using dynamically allocated virtual
: clusters that back swap entries on demand via zswap, zero-filled pages,
: or physical disk.  Eliminate wasted storage space, remove the need for
: static swapfile provisioning, and enable in-memory swap features on
: diskless systems without degrading performance.

I'll take no action at this time - let's see what the other swap
developers make of this.

Sashiko was talkative, as usual:
	https://sashiko.dev/#/patchset/20260825153238.2695446-1-nphamcs@xxxxxxxxx

There are a few pre-existing things in among this, They look legit to
me, from a quick read.  SWAP_USAGE_OFFLIST_BIT should use
BITS_PER_TYPE(atomic_long_t)?