Re: Path forward for Virtualized Swap?
From: Chris Li
Date: Sat Sep 19 2026 - 03:24:21 EST
On Sat, Sep 12, 2026 at 6:52 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> >
> > Is the limit, the heuristic exists only to make "a seriously wild
> > allocation fail" (as documented). But on a vswap-only machine,
> > reasonable allocations fail. Common swap devices, zram, or xswap don't
> > have this problem. One could argue that the size there is just an
> > optimistic guess, the compression ratio is not controllable. But that
> > heuristic is a guess by design, and a plausible number serves it fine.
> > "Unlimited" seems break that.
>
> That cuts both ways, though. If the configured compression space is
> large and compression ratio is poor, it lets through allocations that
> can be considered "seriously wild" for this machine.
>
> It's a filter. I wouldn't say that letting things through is evidence
> that it's working.
>
> Since compression space is backed by memory, it still makes sense to
> me to reference this heuristic to RAM. Cut it off at 2xRAM or 3xRAM
> tops if compression space is available.
What is this "compression space"? Isn't it just a swap entry allocated
by vswap or xswap?
For our deployment, we only compress about 7-10% of the system memory
before performance starts to suffer. The feedback loop will scale it
back. I am very curious do you have actual work load to swap out 100%
of the RAM. I find that very hard to imagine on servers with huge
amounts of memory. I would love to learn more about your swap fault
latency history in those cases.
8PB discussed in other threads seems way too excessive.
> That all being said, I've laid out implications and concerns around
> limiting compression space in this thread, too. Collecting pros and
> cons is fine, but if you bring up cons for the unlimited case, it's
> fair to ask that you engage with cons brought up on the limited case,
> too, so that we can weigh the tradeoffs.
I think having a kernel config with a default that works for most
cases is good enough; maybe add a commandline to override it.. e.g.
200% RAM. If you worry about overflow, you can set yours to MAX which
is ridiculously big. I don't understand why you force others aren't
allowed to set a reasonable default. I do want to have a reasonable
default config. It should be configurable.
Chris