blk-mq: don't redistribute hardware queues on a CPU hotplug event
authorChristoph Hellwig <hch@lst.de>
Wed, 14 Sep 2016 14:18:52 +0000 (16:18 +0200)
committerJens Axboe <axboe@fb.com>
Thu, 15 Sep 2016 14:42:03 +0000 (08:42 -0600)
commit4e68a011428af3211facd932b4003b3fa3ef4faa
tree474b74a7761809a683a4a7d17576d95568e94a33
parent474b313de79e034e269955de23231da769a521b7
blk-mq: don't redistribute hardware queues on a CPU hotplug event

Currently blk-mq will totally remap hardware context when a CPU hotplug
even happened, which causes major havoc for drivers, as they are never
told about this remapping.  E.g. any carefully sorted out CPU affinity
will just be completely messed up.

The rebuild also doesn't really help for the common case of cpu
hotplug, which is soft onlining / offlining of cpus - in this case we
should just leave the queue and irq mapping as is.  If it actually
worked it would have helped in the case of physical cpu hotplug,
although for that we'd need a way to actually notify the driver.
Note that drivers may already be able to accommodate such a topology
change on their own, e.g. using the reset_controller sysfs file in NVMe
will cause the driver to get things right for this case.

With the rebuild removed we will simplify retain the queue mapping for
a soft offlined CPU that will work when it comes back online, and will
map any newly onlined CPU to queue 0 until the driver initiates
a rebuild of the queue map.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
block/blk-mq.c