Re: [PATCH v4 mm-new 2/2] mm/swap: select swap device with default priority round robin

[Baoquan He <bhe@redhat.com>]

On 10/13/25 at 04:40am, Barry Song wrote:
> On Sun, Oct 12, 2025 at 5:14 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Swap devices are assumed to have similar accessing speed if no priority
> > is specified when swapon. It's unfair and doesn't make sense just because
> > one swap device is swapped on firstly, its priority will be higher than
> > the one swapped on later.
> >
> > Here, set all swap devicess to have priority '-1' by default. With this
> > change, swap device with default priority will be selected round robin
> > when swapping out. This can improve the swapping efficiency a lot among
> > multiple swap devices with default priority.
> >
> > Below are swapon output during processes high pressure vm-scability test
> > is being taken:
> >
> > 1) This is pre-commit a2468cc9bfdf, swap device is selectd one by one by
> >    priority from high to low when one swap device is exhausted:
> > ------------------------------------
> > [root@hp-dl385g10-03 ~]# swapon
> > NAME       TYPE      SIZE   USED PRIO
> > /dev/zram0 partition  16G    16G   -1
> > /dev/zram1 partition  16G 966.2M   -2
> > /dev/zram2 partition  16G     0B   -3
> > /dev/zram3 partition  16G     0B   -4
> >
> > 2) This is behaviour with commit a2468cc9bfdf, on node, swap device
> >    sharing the same node id is selected firstly until exhausted; while
> >    on node no swap device sharing the node id it selects the one with
> >    highest priority until exhaustd:
> > ------------------------------------
> > [root@hp-dl385g10-03 ~]# swapon
> > NAME       TYPE      SIZE  USED PRIO
> > /dev/zram0 partition  16G 15.7G   -2
> > /dev/zram1 partition  16G  3.4G   -3
> > /dev/zram2 partition  16G  3.4G   -4
> > /dev/zram3 partition  16G  2.6G   -5
> >
> > 3) After this patch applied, swap devices with default priority are selectd
> >    round robin:
> > ------------------------------------
> > [root@hp-dl385g10-03 block]# swapon
> > NAME       TYPE      SIZE USED PRIO
> > /dev/zram0 partition  16G 6.6G   -1
> > /dev/zram1 partition  16G 6.6G   -1
> > /dev/zram2 partition  16G 6.6G   -1
> > /dev/zram3 partition  16G 6.6G   -1
> >
> > With the change, we can see about 18% efficiency promotion relative to
> > node based way as below. (Surely, the pre-commit a2468cc9bfdf way is
> > the worst.)
> >

Thanks a lot for reviewing, Barry.

> 
> I’m not against the behavior change; but the swapon man page says:
> "
>        Each swap area has a priority, either high or low.  The default
>        priority is low.  Within the low-priority areas, newer areas are
>        even lower priority than older areas.

I didn't see this in man 8 page of swapon, while see it in man 2 page.
Means people may feel that change when they call the call swapon()
syscall, but people may not cares about in script or something like that?

> "
> So my question is whether users still assume that newly added swap areas
> get a lower priority than the older ones?
> 
> I assume the priority decrement isn’t a stable ABI, so this change won’t
> break userspace?

Hmm, I would say that this will change the assumption, BUT I don't start
it. That assumption has been broken since the numa based swap device
choosing at below commit:

commit a2468cc9bfdf ("swap: choose swap device according to numa node").

Before commit a2468cc9bfdf, swapon behaviour is taken strictly as the
man page states. The earlier the swap device is added, the higher its
default priority is. And the highest priority device is used up, then
the 2nd highest priority swap device, and so on in sequence. Below
swapon output demonstrate.
===============================
[root@hp-dl385g10-03 ~]# swapon
NAME       TYPE      SIZE   USED PRIO
/dev/zram0 partition  16G    16G   -1
/dev/zram1 partition  16G 966.2M   -2
/dev/zram2 partition  16G     0B   -3
/dev/zram3 partition  16G     0B   -4

However, after commit a2468cc9bfdf applied, above behaviour had been
changed. I can give an extreme example, imagine on a system with one
NUMA Node, node_id is 0. Then I swapon several swap devices w/o node_id
value (namely node_id is -1), at last I swapon one device with node_id
0. You can see the last one will have the highest priority to be chosen,
then other swap devices.

So I would argue that if people realy care about the default priority,
it has been broken since 2017 when commit a2468cc9bfdf was introduce,
and complaint would be heard since long before. While we didn't hear
complaint, means the default priority doesn't really matter?
> 
> Or if someone sets up Linux assuming that a newer swap file will only be
> used after the older one is full, then this change would break those cases?

Hmm, it could happen, but I doubt people really count on that. I would use
'swapon -p xx' to specify explicit priority to make sure it. In the case you
said, swapped out pages will be swapped in, it's either not guaranteed.

Thanks
Baoquan