summaryrefslogtreecommitdiff
path: root/include/linux/ext2_fs.h
diff options
context:
space:
mode:
authorJohn Garry <john.garry@huawei.com>2021-05-13 15:00:58 +0300
committerJens Axboe <axboe@kernel.dk>2021-05-24 15:47:22 +0300
commitd97e594c51660bea510a387731637b894651e4b5 (patch)
tree75ecde7844bf74c2726730df303786d3bc38e61b /include/linux/ext2_fs.h
parent56b68085e536eff2676108f2f8356889a7dbbf55 (diff)
downloadlinux-d97e594c51660bea510a387731637b894651e4b5.tar.xz
blk-mq: Use request queue-wide tags for tagset-wide sbitmap
The tags used for an IO scheduler are currently per hctx. As such, when q->nr_hw_queues grows, so does the request queue total IO scheduler tag depth. This may cause problems for SCSI MQ HBAs whose total driver depth is fixed. Ming and Yanhui report higher CPU usage and lower throughput in scenarios where the fixed total driver tag depth is appreciably lower than the total scheduler tag depth: https://lore.kernel.org/linux-block/440dfcfc-1a2c-bd98-1161-cec4d78c6dfc@huawei.com/T/#mc0d6d4f95275a2743d1c8c3e4dc9ff6c9aa3a76b In that scenario, since the scheduler tag is got first, much contention is introduced since a driver tag may not be available after we have got the sched tag. Improve this scenario by introducing request queue-wide tags for when a tagset-wide sbitmap is used. The static sched requests are still allocated per hctx, as requests are initialised per hctx, as in blk_mq_init_request(..., hctx_idx, ...) -> set->ops->init_request(.., hctx_idx, ...). For simplicity of resizing the request queue sbitmap when updating the request queue depth, just init at the max possible size, so we don't need to deal with the possibly with swapping out a new sbitmap for old if we need to grow. Signed-off-by: John Garry <john.garry@huawei.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/1620907258-30910-3-git-send-email-john.garry@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'include/linux/ext2_fs.h')
0 files changed, 0 insertions, 0 deletions