On Tue, 2017-08-01 at 00:50 +0800, Ming Lei wrote:
> When hw queue is busy, we shouldn't take requests from
> scheduler queue any more, otherwise IO merge will be
> difficult to do.
> 
> This patch fixes the awful IO performance on some
> SCSI devices(lpfc, qla2xxx, ...) when mq-deadline/kyber
> is used by not taking requests if hw queue is busy.
> 
> Signed-off-by: Ming Lei <ming....@redhat.com>
> ---
>  block/blk-mq-sched.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> index 4ab69435708c..47a25333a136 100644
> --- a/block/blk-mq-sched.c
> +++ b/block/blk-mq-sched.c
> @@ -94,7 +94,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx 
> *hctx)
>       struct request_queue *q = hctx->queue;
>       struct elevator_queue *e = q->elevator;
>       const bool has_sched_dispatch = e && e->type->ops.mq.dispatch_request;
> -     bool did_work = false;
> +     bool can_go = true;
>       LIST_HEAD(rq_list);
>  
>       /* RCU or SRCU read lock is needed before checking quiesced flag */
> @@ -125,7 +125,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx 
> *hctx)
>        */
>       if (!list_empty(&rq_list)) {
>               blk_mq_sched_mark_restart_hctx(hctx);
> -             did_work = blk_mq_dispatch_rq_list(q, &rq_list);
> +             can_go = blk_mq_dispatch_rq_list(q, &rq_list);
>       } else if (!has_sched_dispatch) {
>               blk_mq_flush_busy_ctxs(hctx, &rq_list);
>               blk_mq_dispatch_rq_list(q, &rq_list);
> @@ -136,7 +136,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx 
> *hctx)
>        * on the dispatch list, OR if we did have work but weren't able
>        * to make progress.
>        */
> -     if (!did_work && has_sched_dispatch) {
> +     if (can_go && has_sched_dispatch) {
>               do {
>                       struct request *rq;

Hello Ming,

Please chose a better name for the new variable, e.g. "do_sched_dispatch". 
Otherwise this patch looks fine to me. Hence:

Reviewed-by: Bart Van Assche <bart.vanass...@wdc.com>

Bart.

Reply via email to