Re: Path forward for Virtualized Swap?

[Klara Modin]

On 2026-09-23 08:43:41 -0700, Nhat Pham wrote:
> On Wed, Sep 23, 2026 at 5:52 AM Klara Modin <klarasmodin@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On 2026-09-22 21:10:53 -1000, Chris Li wrote:
> > > On Tue, Sep 22, 2026 at 5:53 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
> > > >
> > > > On Tue, 2026-09-22 at 05:43 -1000, Chris Li wrote:
> > > > > On Tue, Sep 22, 2026 at 5:20 AM Gregory Price <gourry@xxxxxxxxxx>
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Sep 22, 2026 at 03:32:44AM -1000, Chris Li wrote:
> > > > > > > > Right now it has 64GB of memory.
> > > > > > >
> > > > > > > That is exactly my point. You are running 1/8 = 12.5% system ram.
> > > > > > >
> > > > > >
> > > > > > Chris you are missing the point
> > > > > >
> > > > > > Zswap:           8812236 kB
> > > > > > Zswapped:       24927876 kB
> > > > >
> > > > > I am well aware of the point. The 7%-10% data I provided is before
> > > > > compression. After compression, the real saving is about 1.5% - 2%.
> > > > >
> > > > Here I'm at 28% without any issues, with room for
> > > > more.
> > >
> > > 28% is one thing, 100% is a difference beast completely. If you
> > > haven't tried it, don't assume 100% will behave the same as 28%. There
> > > is a point where too much zswap makes the system unusable. It is hard
> > > to pinpoint the exact upper boundary. However, figuring out the upper
> > > bound larger than that exact boundary is not hard at all. I haven't
> > > seen any one can use 100% system RAM sized memory swap out to zswap.
> > > If you have a data point showing what that system with 100% swap to
> > > zswap looks like, please share it.
> > >
> >
> > 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.

Just for completeness, here is later during the second stage of the GCC
17 build:

MemTotal:        3966864 kB
SwapCached:       100488 kB
SwapTotal:      16777212 kB
SwapFree:       16500688 kB
Zswap:            371128 kB
Zswapped:        3995796 kB
AnonPages:       2792748 kB
AnonHugePages:   1026048 kB

And we are past 100 % of MemTotal.

> >
> > 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
> > appreciate the work being put in to decouple zswap from needing a
> > physical swap device to work.
> >
> > > >
> > > > > You are not listening. The boundary was set due to feedback from the
> > > > > application SLO. Those are real deployments not imaginary usage.
> > > > > Please respect the user.
> > > > >
> > > > Different users need different things.
> > > >
> > > > The kernel needs to be able to accommodate all of them.
> > > >
> > > > The kernel default should accommodate the people who
> > > > are least capable of configuring their systems.
> > > >
> > > > Hyperscalers can set their own defaults across their
> > > > fleets. They know how to adjust settings.
> > >
> > > They can use a safe value, e.g., 100% of RAM. Let the people who know
> > > exactly what they want to swap configure the boundary they want.
> >
> > 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.
> >
> 
> Thanks for the data, and for the testing. Please let me know if you
> have any requests or encounter any problems :)

Thanks for the good work!

> 
> And yes, I completely agree with you. We're having a very backward
> conversation. The default should ALWAYS be less hassle for userspace.
> Ergo, as transparent as possible.
> 
> Exposing priority, sizing, etc. is *adding work* to userspace. That's
> the position that needs justification, not the other way around.