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

[David Hildenbrand (Arm)]

On 10/12/26 11:16, Baoquan He wrote:
> Hi Klara,
> 
> On 10/07/26 at 06:28pm, Klara Modin wrote:
>> On 2026-10-03 08:31:22 +0800, Baoquan He wrote:
> ...snip...
>>> The only argument create takes is a priority. The size comes from
>>> xswap.max= at boot, so there is one place to ask for a size and one to
>>> ask for a priority, and a priority can be given per device while a size
>>> cannot:
>>>
>>>   # echo > /sys/kernel/mm/xswap/create          default priority
>>>   # echo 100 > /sys/kernel/mm/xswap/create      priority 100
>>>
>>
>>> The default is the highest priority, SWAP_FLAG_PRIO_MASK. An xswap
>>> device is then the first one tried, ahead of any ordinary swap device.
>>> Setting a lower priority is allowed.
>>
>> Nice, this is now a good default which the user should not have to
>> change.
> 
> Thanks a lot for careful reviewing, and sorry for late reply.
> 
>>
>>>
>>> The device does not move once it exists, so the address space cannot be
>>> changed from this interface either. xswap.max= at boot and this together
>>> are the whole configuration.
> ...snip...
>>> Open items
>>> ----------
>>>
>>> - xswap_create() sets si->pages to the whole address space (twice RAM by
>>>   default) and _enable_swap_info() adds it to nr_swap_pages and
>>>   total_swap_pages, which is what __vm_enough_memory() uses for
>>>   overcommit. That raises the commit limit by 2xRAM for a device whose
>>>   real capacity is bounded by the zswap pool and by how well the workload
>>>   compresses. The question is which semantics overcommit should follow:
>>>   worst-case backing, or the address space.
>>>
>>> - destroy takes a bare swap type. The type is an internal index that
>>>   alloc_swap_info() recycles as soon as SWP_USED clears, so a value read
>>>   earlier can name a different device by the time it is written. The
>>>   swapoff ABI uses a path for this reason. It wants a generation or
>>>   another stable handle.
>>>
>>> - The new interfaces (/sys/kernel/mm/xswap/create and destroy, xswap.max=,
>>>   the new type string in /proc/swaps) are not documented yet.
>>
>> To me it feels a bit weird to have the interface split between a kernel
>> parameter and sysfs, meaning I have to configure this in two places now.
>> As far as I gather, there's also nothing that needs the limit to be
>> fixed at boot since it is applied at creation. If we want to expose this
>> limit to users (as xswap does) it would be nice to have a 'max'
>> shorthand for tha largest possible value, i.e. SWAPFILE_CLUSTER *
>> UNIT_MAX (or whatever it might be in the future). That would I guess in
>> practice give the same behaviour as vm.overcommit_memory=1 which might
>> or might not be desirable.
> 
> 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.

-- 
Cheers,

David