Re: [PATCH v4 00/14] mm, swap: extendable swap devices (xswap phase I)

[Nhat Pham]

On Tue, Oct 13, 2026 at 8:08 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 10/13/26 11:18, Baoquan He wrote:
> > On 10/12/26 at 03:44pm, David Hildenbrand (Arm) wrote:
> >> On 10/12/26 11:16, Baoquan He wrote:
> >>> Hi Klara,
> >>>
> >>> ...snip...
> >>>
> >>> Thanks a lot for careful reviewing, and sorry for late reply.
> >>>
> >>> ...snip...
> >>>
> >>> Thanks for the comment.
> >>>
> >>> Here xswap.max= is a global boot parameter, while not a per-device or
> >>> runtie knob. It sets the space space (si->max) of the xswap device
> >>> at boot and can't change at runtime. So on the two places: the size is
> >>> a global setting, fixed at boot; the priority is per device, it is in
> >>> the create interface. They are different things.
> >>>
> >>> The default is 2xRAM. From our earlier discussion, this is the largest
> >>> size we think is sensible, and in practice I don't think it is not
> >>> reachable in reality. If a system has swapped out 70% of its memory, and
> >>> even more at 100%, it is already doubtful that it can still function
> >>> normally. So 2xRAM is an upper bound, not a target.
> >>
> >> I remember some overcommitted hypervisor setups where people swapped out
> >> significantly more -- without any issues.
> >>
> >> For example, Windows VMs initialize all VM memory when booting up. Afterwards,
> >> you might just have plenty of memory that was touched once but will not really
> >> be used in any near future.
> >>
> >> So I would consider some crazy hypervisor scenarios as well where people
> >> commonly have significant cold memory that is currently not hot (not in the
> >> working set) but might possibly used in some distant future.
> >
> > Hi David,
> >
> > Thanks a lot for the valuable input. This is probably the first first-hand
> > information I have heard about a production environment. And Klara
> > measured about 160% of RAM in zswap on her RISC-V box, so the 2xRAM default
> > is reachable in practice, not just in theory.
> >
> > So I see 2xRAM as a default, not as a cap. xswap.max= already overrides it.
> > After your comment and Klara's numbers, I am open to a larger default, or to
> > a "max" value for the address space. The real limit is still the backing:
> > the zswap pool plus the block devices. The address space should no longer
> > be the limiting factor.
> >
> > By the way, in Windows-VM case you mentioned, is there a block swap backend,
> > or is it zswap alone? If it is zswap alone, the knob that matters is
> > zswap.max_pool_percent, because it sets how much cold memory the pool can
> > hold.
>
> Excellent question: I don't remember all the details. There were talks about
> over-committing up to 400%, and people played with both zswap and zram to
> avoid/reduce IO.
>
> I assume as a safety net people would always look for an additional swap backend
> (that's what I remember, but I don't recall all the details).

I think the better question is why do we have this knob in the first
place. If there is no justification for it, we should not add it.

We should start with the actual usecase, then figure out the
interfaces that best support it, rather than just expose the whole
gamut and burden users with potential misconfigurations. New knobs are
easy to add, but once a knob is added it'd be much more annoying to
prevent user from misspecifying or to deprecate it.