Re: [PATCH v4 mm-new 1/2] mm/swap: do not choose swap device according to numa node

[Baoquan He <bhe@redhat.com>]

On 10/13/25 at 02:09pm, Barry Song wrote:
> > -static int swap_node(struct swap_info_struct *si)
> > -{
> > -       struct block_device *bdev;
> > -
> > -       if (si->bdev)
> > -               bdev = si->bdev;
> > -       else
> > -               bdev = si->swap_file->f_inode->i_sb->s_bdev;
> > -
> > -       return bdev ? bdev->bd_disk->node_id : NUMA_NO_NODE;
> > -}
> > -
> 
> Looking at the code, it seems to have some hardware affinity awareness,
> as it uses the swapfile’s bdev’s node_id. Are we regressing cases where
> each node has a closer block device?

I had talked about this with Chris before I posted v1. We don't need to
worry about this because:

1) Kernel code rarely set disk->node_id, all disks just assign
NUMA_NO_NODE to it except of these:

drivers/nvdimm/pmem.c <<pmem_attach_disk>>
drivers/md/dm.c <<alloc_dev>>

For intel ssd Aaron introduced the node based si choosing is for, it
should be Optane which has been discontinued. It could be wrong, then
hope intel can help test so that we can see what impact is brought in.

2) The gap between disk io and memory accessing
Usually memory accessing is nanosecond level, while disk io is
microsecond level, HDD even could be at millisecond. The node affinity
saving nanoseconds is negligible compared to the disk's own acessing
speed. This includes pmem, its io is more than ten times or even more
than memory accessing.

If there's a real system which owns disks belonging to NUMA nodes, we
can test to see if the new round robin way is better or worse then the
node based way.

Thanks
Baoquan