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 <bvanassche@xxxxxxx>
>> Cc: Hannes Reinecke <hare@xxxxxxxx>
>> Cc: Damien Le Moal <damien.lemoal@xxxxxxx>
>> Cc: Dave Chinner <dchinner@xxxxxxxxxx>
>> Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx>
>> ---
>> 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: stable@xxxxxxxxxxxxxxx
> 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.
--
Jens Axboe
