Re: Path forward for Virtualized Swap?

[Yosry Ahmed]

On Fri, Oct 23, 2026 at 11:48 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> 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?
>
> Adding @Wei Xu for this.

Actually adding Wei this time :)