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 02:17pm, Barry Song wrote:
> On Mon, Oct 13, 2025 at 11:58 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > 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.
> 
> I assume this adds logic to prefer swapping to the closer swapfile first,
> while still maintaining the old behavior for non-NUMA cases.

But it still change the traditional behaviour, right?
The old man 2 page of swapon obviously doesn't state the prefer swapping
to the closer swapfile first on NUMA, while still maintain the old
behaviour for non-NUMA cases.

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

> 
> >
> > 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.
> 
> Personally, I also dislike the behavior where a newer swap file
> automatically gets a lower priority than an older one. However, since
> we have a rule to never break userspace, is this considered such a
> case? Or at least, do we need to update the man page as well?

As discussed above, the rule on swapon had been broken. Of course, I can
update the man 2 page of swapon. There's no change to man 8 page of
swapon, because it's not mentioning the default priority thing.

> 
> BTW, we can achieve all the benefits of the round-robin “18%
> efficiency boost” once users set an explicit priority in userspace for
> the four zRAMs you’re using?

Not sure if I got you correctly. The 18% boost is only related to
default priority. If user sets explicit priority via 'swapon -p xx', 
nothing changed.