| Message ID | 20170726201934.4940-1-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/26/2017 02:19 PM, Christoph Hellwig wrote: > This avoids having to deal with the nr_hw_queues = 1 case in the various > queue mapping helpers by special casing it in the blk-mq core. Why special case it at all? If ->map_queues() is properly written, the single queue case should just fall out naturally. I don't see why 1 should be any different than 2, 4, or N.
On Wed, Jul 26, 2017 at 02:40:50PM -0600, Jens Axboe wrote: > On 07/26/2017 02:19 PM, Christoph Hellwig wrote: > > This avoids having to deal with the nr_hw_queues = 1 case in the various > > queue mapping helpers by special casing it in the blk-mq core. > > Why special case it at all? If ->map_queues() is properly written, > the single queue case should just fall out naturally. I don't see > why 1 should be any different than 2, 4, or N. Because 1 means everything maps to queue 0 and there is no point in asking any lower layers for a specific mapping. We could instead special case it in pci, virtio and the upcoming rdma handler, or we could just do it once in the core and get same result with less overhead.
On 07/27/2017 07:26 AM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 02:40:50PM -0600, Jens Axboe wrote: >> On 07/26/2017 02:19 PM, Christoph Hellwig wrote: >>> This avoids having to deal with the nr_hw_queues = 1 case in the various >>> queue mapping helpers by special casing it in the blk-mq core. >> >> Why special case it at all? If ->map_queues() is properly written, >> the single queue case should just fall out naturally. I don't see >> why 1 should be any different than 2, 4, or N. > > Because 1 means everything maps to queue 0 and there is no point > in asking any lower layers for a specific mapping. We could instead > special case it in pci, virtio and the upcoming rdma handler, or > we could just do it once in the core and get same result with less > overhead. Sure, my point is that the nr_queues == 1 case should just naturally fall out of the mapping function, it's no more special than the other ones.
diff --git a/block/blk-mq.c b/block/blk-mq.c index 041f7b7fa0d6..50d1f069d83b 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2458,9 +2458,20 @@ static int blk_mq_alloc_rq_maps(struct blk_mq_tag_set *set) return 0; } +static int blk_mq_map_single_queue(struct blk_mq_tag_set *set) +{ + int cpu; + + for_each_possible_cpu(cpu) + set->mq_map[cpu] = 0; + return 0; +} + static int blk_mq_update_queue_map(struct blk_mq_tag_set *set) { - if (set->ops->map_queues) + if (set->nr_hw_queues == 1) + return blk_mq_map_single_queue(set); + else if (set->ops->map_queues) return set->ops->map_queues(set); else return blk_mq_map_queues(set);
This avoids having to deal with the nr_hw_queues = 1 case in the various queue mapping helpers by special casing it in the blk-mq core. Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Shaohua Li <shli@kernel.org> --- block/blk-mq.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)