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

[Klara Modin <klarasmodin@gmail.com>]

Hi Baoquan,

On 2026-10-12 17:16:22 +0800, 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'm just not sure this is the case. An application could have a
relatively small working set but a much larger amount of cold memory it
rarely touches. In my GCC 17 example, I saw even greater ratios later in
the build process. This is from your previous xswap version where I got
around the 2x RAM limit by using multiple xswap devices:

MemTotal:        3966828 kB
SwapCached:          868 kB
SwapTotal:      80232412 kB
SwapFree:       69467760 kB
Zswap:            792048 kB
Zswapped:        6342024 kB
AnonPages:       2072820 kB
AnonHugePages:      4096 kB

This is almost 160 % of RAM in zswap and is getting close to the limit
in practice.

In addition, if I read your writeback series correctly, if data from
xswap is written back to a block device, the space of the written back
data cannot be reused in the xswap device (please correct me if I am
wrong). For low memory systems, I frequently set aside a lot more swap
than they have memory. If I do not grow the xswap address space size, I
could risk it getting full if enough of the block-based swap is used.

Looking at the example again, about 10 GiB of swap is reported as used,
but some of that is being reported twice (once through xswap and once
through the backing device) due to being written back (which I still
think is not so great). In this case, the system has 16 GiB of
block-based swap, meaning that the default limit would leave the xswap
device full if even half of it is used through writeback. If I would
only have a single default-sized xswap device in this example I would
likely have hit this in practice.

> 
> On the max short name: it would set the address space to the largest value
> the format allows. As you said, that is close to vm.overcommit_memory=1,
> and it is not a real capacity, so we may not want it as the default.
> 
> We keep xswap.max= only for special needs. Otherwise we may not need to
> change it.
> 
> Chris suggested a CONFIG option for the size. While CONFIG is not friendly
> to distros, you must rebuild the kernel to change it.

For my use case I would probably prefer a CONFIG option if that is the
only way. I typically build all my kernels on the same machine and send
the image either directly or for netboot. Setting the kernel command
line can be very different depending on the system (Different EFI
bootloaders, U-Boot and all its vendor versions).

> 
> By the way, I remember you mentioned you ever did a test making swapped
> out pages about 110% of system RAM, could you share your testing steps
> or scripts so that I can give it a shot on my testing system? If it's
> not convenient, then never mind.

It's nothing fancy. I just build the Gentoo package for the GCC 17
pre-release on my RISC-V BPI-F3. As I understand, the pre-release
sources will also enables some extra debugging and correctness checks
which will make the build slower and maybe also use more memory. Note
that I do not see the same memory usage on other arches which is I
believe due to the implementation of the RISC-V autovectorisation (GCC
14 saw a large jump and that was the release which added it). I do add
configure options --with-matchpd-partitions=20 and
--with-insnemit-partitions=50 since especially insn-recog.cc tends to be
huge and the default partition of 10 it will still be quite large.

My datapoints are from just dumping some fields of /proc/meminfo every
ten seconds.

> 
> Thanks
> Baoquan

Regards,
Klara Modin