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

[Chris Li <chrisl@kernel.org>]

On Tue, Oct 14, 2025 at 9:29 PM Barry Song <21cnbao@gmail.com> wrote:
>
> On Wed, Oct 15, 2025 at 6:49 AM Chris Li <chrisl@kernel.org> wrote:
> >
> > On Sun, Oct 12, 2025 at 11:17 PM Barry Song <21cnbao@gmail.com> wrote:
> > > >
> > > > 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.
> >
> > That commit a2468cc9bfdf changes the default behavior of the swapon
> > which does not specify a priority.
> > If you claim the revert breaks the user behavior, that commit also
> > breaks the user behavior as well.
> >
> > > > 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?
> >
> > See above, we should update the man page as well.
> >
> > If the a2468cc9bfdf can break user default swapon behavior by
> > introducing node_id in the first place. It is totally justifiable to
> > break it again to revert it. I fail to see the logic why the breaking
> > rule only applies to the revert but not the commit introducing it in
> > the first place.
>
> I’m actually referring to the part below, which changes the default priority
> to -1 for all swapfiles while it used to be -n, -n -1, -n -2 , -n -3....
>
> -       if (prio >= 0)
> -               si->prio = prio;
> -       else
> -               si->prio = --least_priority;
>
> I agree the NUMA-ID swap patch (a2468cc9bfdf) has partially broken the man
> page, but only for very rare hardware whose block device has a NUMA node ID
> (yes, the man page should have been updated back then). Now we’re breaking
> the man page for all hardware, so I think it’s even more important to
> highlight that in the man page at this point.

Right, I think we are in agreement that the man page needs to be
updated as well. Thanks for catching that.

Chris