Re: [PATCH v5 00/21] Virtual Swap Space

[Yosry Ahmed <yosry@kernel.org>]

On Fri, Mar 20, 2026 at 12:27:14PM -0700, Nhat Pham wrote:
> 
> This patch series is based on 6.19. There are a couple more
> swap-related changes in mainline that I would need to coordinate
> with, but I still want to send this out as an update for the
> regressions reported by Kairui Song in [15]. It's probably easier
> to just build this thing rather than dig through that series of
> emails to get the fix patch :)
> 
> Changelog:
> * v4 -> v5:
>     * Fix a deadlock in memcg1_swapout (reported by syzbot [16]).
>     * Replace VM_WARN_ON(!spin_is_locked()) with lockdep_assert_held(),
>       and use guard(rcu) in vswap_cpu_dead
>       (reported by Peter Zijlstra [17]).
> * v3 -> v4:
>     * Fix poor swap free batching behavior to alleviate a regression
>       (reported by Kairui Song).
>     * Fix assorted kernel build errors reported by kernel test robots
>       in the case of CONFIG_SWAP=n.
> * RFC v2 -> v3:
>     * Implement a cluster-based allocation algorithm for virtual swap
>       slots, inspired by Kairui Song and Chris Li's implementation, as
>       well as Johannes Weiner's suggestions. This eliminates the lock
> 	  contention issues on the virtual swap layer.
>     * Re-use swap table for the reverse mapping.
>     * Remove CONFIG_VIRTUAL_SWAP.
>     * Reducing the size of the swap descriptor from 48 bytes to 24
>       bytes, i.e another 50% reduction in memory overhead from v2.
>     * Remove swap cache and zswap tree and use the swap descriptor
>       for this.
>     * Remove zeromap, and replace the swap_map bytemap with 2 bitmaps
>       (one for allocated slots, and one for bad slots).
>     * Rebase on top of 6.19 (7d0a66e4bb9081d75c82ec4957c50034cb0ea449)
> 	* Update cover letter to include new benchmark results and discussion
> 	  on overhead in various cases.
> * RFC v1 -> RFC v2:
>     * Use a single atomic type (swap_refs) for reference counting
>       purpose. This brings the size of the swap descriptor from 64 B
>       down to 48 B (25% reduction). Suggested by Yosry Ahmed.
>     * Zeromap bitmap is removed in the virtual swap implementation.
>       This saves one bit per physical swapfile slot.
>     * Rearrange the patches and the code change to make things more
>       reviewable. Suggested by Johannes Weiner.
>     * Update the cover letter a bit.
> 
> This patch series implements the virtual swap space idea, based on Yosry's
> proposals at LSFMMBPF 2023 (see [1], [2], [3]), as well as valuable
> inputs from Johannes Weiner. The same idea (with different
> implementation details) has been floated by Rik van Riel since at least
> 2011 (see [8]).

Unfortuantely, I haven't been able to keep up with virtual swap and swap
table development, as my time is mostly being spent elsewhere these
days. I do have a question tho, which might have already been answered
or is too naive/stupid -- so apologies in advance.

Given the recent advancements in the swap table and that most metadata
and the swap cache are already being pulled into it, is it possible to
use the swap table in the virtual swap layer instead of the xarray?

Basically pull the swap table one layer higher, and have it point to
either a zswap entry or a physical swap slot (or others in the future)?
If my understanding is correct, we kinda get the best of both worlds and
reuse the integration already done by the swap table with the swap
cache, as well as the lock paritioning.

In this world, the clusters would be in the virtual swap space, and we'd
create the clusters on-demand as needed.

Does this even work or make the least amount of sense (I guess the
question is for both Nhat and Kairui)?