Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Sat, Sep 12, 2026 at 2:01 AM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> On Thu, Sep 10, 2026 at 12:42 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > On Tue, Sep 8, 2026 at 11:30 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> > >
> > > On Mon, Sep 07, 2026 at 01:51:31PM +0800, Kairui Song wrote:
> > > > Where I've ended up is that unbounded growth is a real concern. On a
> > > > host with no memcg limit (root cgroup, and most desktop and embedded
> > > > setups), an unlimited pool means usage can keep growing, with no
> > > > admin visible ceiling at all. I'm not attached to xswap's percent of RAM
> > > > knob specifically, but I do think some kind of bound makes sense.
> > >
> > > Swap space is just process virtual address space, no?
> > >
> > > Swap entries already have one or more page table entries pointing to
> > > them, which in turn are managed by trees of vm_area_structs. That
> > > means rlimits apply, overcommit protection applies, and OOM killer
> > > attribution works as well (oom_badness()).
> >
> > I tested this theory. I spinned up a process, and let it spam 0-filled
> > memory + swap these pages out continually.
> >
> > As you predicted, oom-killer picked it up eventually. The host was
> > (and is) intact otherwise :)
>
> Good to know the kill path works. But I think the accounting side cuts the
> other way? Won't that conversely underestimate the host's ability to
> handle memory alloc? Not to mention a lot of application are
> swap  space aware, some built in logics like e.g. with vm_enough_memory:
>
> On a 1G machine with vswap enabled:
> [    0.241906] vswap: created virtual swap device (2199023255040 pages)
>
> a 2G sparse anonymous allocation fails:
> [   46.044002] __vm_enough_memory: pid: 1129, comm: search_agent,
> bytes: 2147483648 not enough memory for the allocation.
>
> The default "Heuristic overcommit handling" policy is meant to handle
> seriously wild allocation (as documented, and it's named as
> OVERCOMMIT_GUESS).
> totalram_pages() + total_swap_pages
>
> 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.

Oh yeah that needs fixing - thanks for digging that one out!

I'm not sure the answer is keeping "totalram_pages() +
total_swap_pages" though. That makes some amount of sense when the
backend is disk swap - 1 swap slot == 1 page in memory, so it
represents a concrete amount. With compression swap backend in the
picture it's very murky.

I think what Johannes proposed makes a lot of sense. Maybe also
keeping physical swap pages in:

pages = totalram_pages() + total_swap_pages
if (vswap_is_enabled() && zswap_is_enabled())
   pages += 2 * totalram_pages();

i.e just RAM x 3 + physical swap pages. I think this is a
"good-enough" gate. If users truly believe their memory is more
compressible than that (and for some reason they really need big
allocations like this), yes I think they should with the overcommit
mode :)

I'll include this heuristics in v5.