Re: Path forward for Virtualized Swap?
From: Klara Modin
Date: Thu Sep 24 2026 - 03:21:16 EST
On 2026-09-24 13:51:50 +0800, Baoquan He wrote:
> On 09/23/26 at 02:52pm, Klara Modin wrote:
> > Hi,
> >
...
> >
> > Chiming in as more of a user perspective.
> >
> > On my 4 GiB BPI-F3, I can reach more than 10:1 compression ratio on
> > zswap during some parts when building GCC 17 snapshots. E.g:
> >
> > MemTotal: 3966864 kB
> > SwapCached: 31872 kB
> > SwapTotal: 16777212 kB
> > SwapFree: 16638128 kB
> > Zswap: 280140 kB
> > Zswapped: 2859840 kB
> > AnonPages: 2927376 kB
> > AnonHugePages: 1409024 kB
> >
> > While this is 72 % rather than the 100 % you asked for, I think this
> > shows that what size a potential limit on the uncompressed size of zswap
> > is suitable heavily depends on the workload.
> >
> > I have been using vswap consistently on all my machines since about
> > August, and I have also tried one or two versions of xswap (but the
> > current lack of writeback makes it inconvenient for me). I really
>
> Thanks for testing xswap and reporting issue on xswap rfc v3.
>
> xswap has writeback now. I only built foundation for xswap, while
> writeback part was left to other people for collaboration. Finally
> I added it.
>
> [RFC PATCH 00/17] mm, swap: xswap writeback to a physical backend
> https://lore.kernel.org/all/20260920072043.430390-1-hebaoquan@xxxxxxxxxx/T/#u
>
Thanks, I'll give it another try when I have time.
>
> > appreciate the work being put in to decouple zswap from needing a
> > physical swap device to work.
> >
...
> >
> > My personal preference would be for a default uncapped (or very high,
> > and I don't think 100 % of RAM is high) limit on the uncompressed data
> > which is backed by zswap, since that would mean one less knob to tune.
> >
> > >
> > > Chris
> >
> > Regards,
> > Klara Modin