Re: Path forward for Virtualized Swap?

[Nhat Pham]

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.