Re: [RFC PATCH v2 00/18] Virtual Swap Space

[YoungJun Park <youngjun.park@lge.com>]

On Tue, Apr 29, 2025 at 04:38:28PM -0700, Nhat Pham wrote:
> Changelog:
> * v2:
> 	* Use a single atomic type (swap_refs) for reference counting
> 	  purpose. This brings the size of the swap descriptor from 64 KB
> 	  down to 48 KB (25% reduction). Suggested by Yosry Ahmed.
> 	* Zeromap bitmap is removed in the virtual swap implementation.
> 	  This saves one bit per phyiscal swapfile slot.
> 	* Rearrange the patches and the code change to make things more
> 	  reviewable. Suggested by Johannes Weiner.
> 	* Update the cover letter a bit.

Hi Nhat,

Thank you for sharing this patch series.
I’ve read through it with great interest.

I’m part of a kernel team working on features related to multi-tier swapping,
and this patch set appears quite relevant
to our ongoing discussions and early-stage implementation.

I had a couple of questions regarding the future direction.

> * Multi-tier swapping (as mentioned in [5]), with transparent
>   transferring (promotion/demotion) of pages across tiers (see [8] and
>   [9]). Similar to swapoff, with the old design we would need to
>   perform the expensive page table walk.

Based on the discussion in [5], it seems there was some exploration
around enabling per-cgroup selection of multiple tiers.
Do you envision the current design evolving in a similar direction
to those past discussions, or is there a different direction you're aiming for?

>   This idea is very similar to Kairui's work to optimize the (physical)
>   swap allocator. He is currently also working on a swap redesign (see
>   [11]) - perhaps we can combine the two efforts to take advantage of
>   the swap allocator's efficiency for virtual swap.

I noticed that your patch appears to be aligned with the work from Kairui.
It seems like the overall architecture may be headed toward introducing
a virtual swap device layer.
I'm curious if there’s already been any concrete discussion
around this abstraction, especially regarding how it might be layered over
multiple physical swap devices?

From a naive perspective, I imagine that while today’s swap devices
are in a 1:1 mapping with physical devices,
this virtual layer could introduce a 1:N relationship —
one virtual swap device mapped to multiple physical ones.
Would this virtual device behave as a new swappable block device
exposed via `swapon`, or is the plan to abstract it differently?

Thanks again for your work, 
and I would greatly appreciate any insights you could share.

Best regards,  
YoungJun Park