Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Fri, Oct 23, 2026 at 10:24 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Mon, Oct 19, 2026 at 5:35 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > On Mon, Oct 19, 2026 at 5:28 AM David Hildenbrand (Arm)
> > <david@xxxxxxxxxx> wrote:
> > >
> > > On 10/19/26 14:24, Nhat Pham wrote:
> > >
> > > I'm traveling this week, so it's a bit tricky. I cannot make Thursday morning.
> > >
> > > On Thursday I'll be traveling back from Cambridge. But hang on.
> > >
> > > My plan lands on Oct 22, 11:10 PM. I should be home around Friday 1.30am - 2am.
> > >
> > > I could just naturally join that day.
> > >
> > > So one day later would work for me.
> >
> > Would that be too rushed for you? :)
> >
> > For everyone's convenience, this would be the time slot:
> >
> > PDT: Thu Oct 22, 5:00 PM
> > EDT: Thu Oct 22, 8:00 PM
> > Europe: Fri Oct 23, 2:00 AM
> > China: Fri Oct 23, 8:00 AM
>
> Hi folks,
>
> Thanks everyone for attending - I didn’t realize swap was so well loved :)
>
> I took the liberty to summarize the points being discussed - please let
> me know if I missed anything or misunderstood any points:
>
> * Swapfile sizing: Kernel kept swap slots after read faults to save IOs
> if these pages are swapped out again, and thus needed swap occupancy
> (and hence static size) for a heuristics to trigger reclaim of these
> swap-cache-only swap slots. However, this is not useful for fast
> compressed backend, and zswap invalidates its compressed copy on page
> fault anyway. Vswap does not need this heuristics because it just
> frees up the swap slots eagerly on page fault for in-memory backends,
> and rely on the existing slot reclaimer for physical swap backends.
>
> * Logical footprint limits and charging: cgroupv1 allows logical memory
> footprint limits (unique page tables). Cgroupv2 controls physical
> memory and swap resources separately instead. While virtual swap
> entries continue to count towards memsw, cgroupv2 counts only the
> actual resources they consumed - post-compression size in
> memory.current, and nothing in memory.swap.current. While cgroupv1
> continues to be supported in its current state, a cgroupv2 transition
> will present a problem for memsw users that still needs to be worked
> out in some form of overcommit control.
>
> * Swapoff: this was brought up as a request, but we ran out of time
> before we could discuss the motivations and use cases behind them.
> Folks interested, could you explain as a follow-up?
>
> * VM_SPARSE v.s xarray: no performance difference between vswap v.s
> part 1 of the xswap’s patch series. With all 3 parts, there is a win
> for xswap, according to Baoquan’s testing.
>
> Let us keep the communication line open and coordinate on the next
> steps.

Hi folks,

We made some nice progress last time, but I think it will take more
collaborative efforts to drive this one through :)

I'd love it if we can meet again, say next week (making this
bi-weekly). Some agenda on top of my mind right now:

1. Use cases that are glossed over last time (swapoff).

2. More interface design.

etc.

I can bring some concrete proposal to the floor so that we have
something to work off of.

Regarding the time - would shifting the meeting by 12 hours (so that
it's morning in NorthAm, evening in China, and afternoon for Europe)
help European folks attend? I'm fine with the old time otherwise.

(BTW, we'd have 5 timezones to accommodate, because where I live,
Vancouver/BC, will be in its own unique timezone starting Nov).

Best,
Nhat