[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aDlUgVFdA7rCUvHx@yjaykim-PowerEdge-T330>
Date: Fri, 30 May 2025 15:47:29 +0900
From: YoungJun Park <youngjun.park@....com>
To: Nhat Pham <nphamcs@...il.com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, hannes@...xchg.org,
hughd@...gle.com, yosry.ahmed@...ux.dev, mhocko@...nel.org,
roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
muchun.song@...ux.dev, len.brown@...el.com,
chengming.zhou@...ux.dev, kasong@...cent.com, chrisl@...nel.org,
huang.ying.caritas@...il.com, ryan.roberts@....com,
viro@...iv.linux.org.uk, baohua@...nel.org, osalvador@...e.de,
lorenzo.stoakes@...cle.com, christophe.leroy@...roup.eu,
pavel@...nel.org, kernel-team@...a.com,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
linux-pm@...r.kernel.org, peterx@...hat.com, gunho.lee@....com,
taejoon.song@....com, iamjoonsoo.kim@....com
Subject: Re: [RFC PATCH v2 00/18] Virtual Swap Space
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
Powered by blists - more mailing lists