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

["David Hildenbrand (Arm)" <david@kernel.org>]

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).

-- 
Cheers,

David