On 2019/09/27 10:32, Jens Axboe wrote: > On 9/27/19 7:25 PM, Damien Le Moal wrote: >> On 2019/09/27 0:25, Ming Lei wrote: >>> Now in case of real MQ, io scheduler may be bypassed, and not only this >>> way may hurt performance for some slow MQ device, but also break zoned >>> device which depends on mq-deadline for respecting the write order in >>> one zone. >>> >>> So don't bypass io scheduler if we have one setup. >>> >>> This patch can double sequential write performance basically on MQ >>> scsi_debug when mq-deadline is applied. >>> >>> Cc: Bart Van Assche <[email protected]> >>> Cc: Hannes Reinecke <[email protected]> >>> Cc: Damien Le Moal <[email protected]> >>> Cc: Dave Chinner <[email protected]> >>> Signed-off-by: Ming Lei <[email protected]> >>> --- >>> block/blk-mq.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/block/blk-mq.c b/block/blk-mq.c >>> index 20a49be536b5..d7aed6518e62 100644 >>> --- a/block/blk-mq.c >>> +++ b/block/blk-mq.c >>> @@ -2003,6 +2003,8 @@ static blk_qc_t blk_mq_make_request(struct >>> request_queue *q, struct bio *bio) >>> } >>> >>> blk_add_rq_to_plug(plug, rq); >>> + } else if (q->elevator) { >>> + blk_mq_sched_insert_request(rq, false, true, true);> } else >>> if (plug && !blk_queue_nomerges(q)) { >>> /* >>> * We do limited plugging. If the bio can be merged, do that. >>> @@ -2026,8 +2028,8 @@ static blk_qc_t blk_mq_make_request(struct >>> request_queue *q, struct bio *bio) >>> blk_mq_try_issue_directly(data.hctx, same_queue_rq, >>> &cookie); >>> } >>> - } else if ((q->nr_hw_queues > 1 && is_sync) || (!q->elevator && >>> - !data.hctx->dispatch_busy)) { >>> + } else if ((q->nr_hw_queues > 1 && is_sync) || >>> + !data.hctx->dispatch_busy) { >>> blk_mq_try_issue_directly(data.hctx, rq, &cookie); >>> } else { >>> blk_mq_sched_insert_request(rq, false, true, true); >>> >> >> I think this patch should have a Cc: [email protected] >> This fixes a problem existing since we added deadline zone write-locking with >> commit 5700f69178e9 ("mq-deadline: Introduce zone locking support"). > > I'd rather not mark it for stable until it's been in the kernel for some > weeks at least, since we are potentially dealing with behavioral change > for everyone. We've been burnt by stuff like this in the past. > > That said, this patch could be a candidate. Let's revisit in a few weeks. >
OK. Thanks ! -- Damien Le Moal Western Digital Research
