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

[Baoquan He <baoquan.he@linux.dev>]

On 10/13/26 at 05:08pm, David Hildenbrand (Arm) 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 see, thanks. I will take this as a real use case and think how to
handle it.