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

On Thu, Aug 27, 2026 at 8:07 PM Andrew Morton [off-list ref] wrote:

On Tue, 25 Aug 2026 08:32:26 -0700 Nhat Pham [off-list ref] wrote:

quoted

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.

Hi Andrew!

Thanks for taking a look. I'm also waiting for review from fellow swappers :)

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

I've been going through the sashiko review on every iterations!
Hopefully the list will keep getting smaller and smaller.

There are a couple of false positives, as per usual (the first issue
for e.g was intended behavior, at the point of that patch at least).

That said:

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)?

I think that might be pre-existing. Maybe we just have not seen users
who used 4TB+ swapfile yet?

Might be worth just putting in a quick fix independent of this patch
series just in case.

Let me see if I can quickly whip sth up :)