blk-mq: Build default queue map via group_cpus_evenly()
authorMing Lei <ming.lei@redhat.com>
Tue, 27 Dec 2022 02:29:05 +0000 (10:29 +0800)
committerThomas Gleixner <tglx@linutronix.de>
Tue, 17 Jan 2023 17:50:06 +0000 (18:50 +0100)
commit6a6dcae8f486c3f3298d0767d34505121c7b0b81
treec6d0f6cdedcfb200322d5b891ca2029b857d569b
parentf7b3ea8cf72f3d6060fe08e461805181e7450a13
blk-mq: Build default queue map via group_cpus_evenly()

The default queue mapping builder of blk_mq_map_queues doesn't take NUMA
topo into account, so the built mapping is pretty bad, since CPUs
belonging to different NUMA node are assigned to same queue. It is
observed that IOPS drops by ~30% when running two jobs on same hctx
of null_blk from two CPUs belonging to two NUMA nodes compared with
from same NUMA node.

Address the issue by reusing group_cpus_evenly() for building queue mapping
since group_cpus_evenly() does group cpus according to CPU/NUMA locality.

Also performance data becomes more stable with this given correct queue
mapping is applied wrt. numa locality viewpoint, for example, on one two
nodes arm64 machine with 160 cpus, node 0(cpu 0~79), node 1(cpu 80~159):

1) modprobe null_blk nr_devices=1 submit_queues=2

2) run 'fio(t/io_uring -p 0 -n 4 -r 20 /dev/nullb0)', and observe that
IOPS becomes much stable on multiple tests:

 - unpatched: IOPS is 2.5M ~ 4.5M
 - patched:   IOPS is 4.3M ~ 5.0M

Lots of drivers may benefit from the change, such as nvme pci poll,
nvme tcp, ...

Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/20221227022905.352674-7-ming.lei@redhat.com
block/blk-mq-cpumap.c