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

[Nhat Pham]

On Thu, Aug 27, 2026 at 8:07 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.

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@xxxxxxxxx

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