Re: [PATCH] mm/swapfile.c: select the swap device with default priority round robin

[Baoquan He <bhe@redhat.com>]

On 09/25/25 at 11:25am, Chris Li wrote:
> On Wed, Sep 24, 2025 at 6:55 PM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 09/24/25 at 08:54am, Chris Li wrote:
> > > Hi Baoquan,
> > >
> > > Very exciting numbers. I have always suspected the per node priority
> > > is not doing much contribution in the new swap allocator world. I did
> > > not expect it to have negative contributions.
> >
> > Yes.
> >
> > While compared with the very beginning, there has been some progress.
> > At the very beginning, there was one plist and swap device will get
> > priority from -1 then downwards by default, then all cpus will exhaust
> > the swap device of pirority '-1', then select swap device of priority
> > '-2' to exhaust, then -3, .... I think node-based adjustment distribute
> > the pressure of contending lock on one swap device a little bit.
> > However, in node they still try to exhaust one swap device by node's
> > CPUs; and nodes w/o swap device attached still try to exhaust swap
> > device one by one in the order of priority.
> >
> > >
> > > On Wed, Sep 24, 2025 at 2:18 AM Baoquan He <bhe@redhat.com> wrote:
> > > >
> > > > Currently, on system with multiple swap devices, swap allocation will
> > > > select one swap device according to priority. The swap device with the
> > > > highest priority will be chosen to allocate firstly.
> > > >
> > > > People can specify a priority from 0 to 32767 when swapon a swap device,
> > > > or the system will set it from -2 then downwards by default. Meanwhile,
> > > > on NUMA system, the swap device with node_id will be considered first
> > > > on that NUMA node of the node_id.
> > >
> > > That behavior was introduced by: a2468cc9bfdf ("swap: choose swap
> > > device according to numa node")
> > > You are effectively reverting that patch and the following fix up
> > > patches on top of that.
> > > The commit message or maybe the title should reflect the reversion nature.
> > >
> > > If you did more than the simple revert plus fix up, please document
> > > what additional change you make in this patch.
> >
> > Sure, I will mention commit a2468cc9bfdf and my patch reverts it, on top
> > of that default priority of swap device will be set to '-1' so that all
> > swap devices with default priority will be chosen round robin. Like
> > this, the si->lock contention can be greatly reduced.
> 
> Just curious, is setting to "-1" matches to kernel behavior before
> a2468cc9bfdf, if not what is the behavior before a2468cc9bfdf.

It should be like below. It's not a real output, I made the data to show
what it looks like.

# swapon
NAME       TYPE      SIZE  USED PRIO
/dev/zram0 partition  16G 15.8G   -1
/dev/zram1 partition  16G    0B   -2
/dev/zram2 partition  16G    0B   -3
/dev/zram3 partition  16G    0B   -4

I just apply this patch and set the priority to emulate the kerel
behavirour before a2468cc9bfdf. In kernel before a2468cc9bfdf, it sets
priority to swap device from -1 downwards. There's only one
swap_avail_head plist for all CPUs. The behaviour is very much like below:

[root@hp-dl385g10-03 ~]# swapon
NAME       TYPE      SIZE  USED PRIO
/dev/zram0 partition  16G    0B    0
/dev/zram1 partition  16G    0B    1
/dev/zram2 partition  16G    0B    2
/dev/zram3 partition  16G 14.3G    3