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

[Chris Li <chrisl@kernel.org>]

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.

>
> 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?

Possible, it also depends on your setup. The zRAM experiment is a hack
to simulate the node_id behavior. The reason for that hack is that the
kernel does not have a node_id block device driver can use for the
node_id swapfile testing.

Back to the swapfile si->lock. Yes, that is a contented lock. It will
benefit the user if split the swapfile into a dozen of them instead of
just one.  That is even with all the swap allocator optimizations to
reduce the si->lock contention.

Chris