All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly()
@ 2017-03-14 14:57 Jens Axboe
  2017-03-14 15:17 ` Bart Van Assche
  2017-03-14 17:48 ` Omar Sandoval
  0 siblings, 2 replies; 5+ messages in thread
From: Jens Axboe @ 2017-03-14 14:57 UTC (permalink / raw)
  To: linux-block

If we have scheduling enabled, we jump directly to insert-and-run.
That's fine, but we run the queue async and we don't pass in information
on whether we can block from this context or not. Fixup both these
cases.

Signed-off-by: Jens Axboe <axboe@fb.com>

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 159187a28d66..4196d6bee92d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1434,7 +1434,8 @@ static blk_qc_t request_to_qc_t(struct blk_mq_hw_ctx *hctx, struct request *rq)
 	return blk_tag_to_qc_t(rq->internal_tag, hctx->queue_num, true);
 }
 
-static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie)
+static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie,
+				      bool can_block)
 {
 	struct request_queue *q = rq->q;
 	struct blk_mq_queue_data bd = {
@@ -1475,7 +1476,7 @@ static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie)
 	}
 
 insert:
-	blk_mq_sched_insert_request(rq, false, true, true, false);
+	blk_mq_sched_insert_request(rq, false, true, false, can_block);
 }
 
 /*
@@ -1569,11 +1570,11 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 
 		if (!(data.hctx->flags & BLK_MQ_F_BLOCKING)) {
 			rcu_read_lock();
-			blk_mq_try_issue_directly(old_rq, &cookie);
+			blk_mq_try_issue_directly(old_rq, &cookie, false);
 			rcu_read_unlock();
 		} else {
 			srcu_idx = srcu_read_lock(&data.hctx->queue_rq_srcu);
-			blk_mq_try_issue_directly(old_rq, &cookie);
+			blk_mq_try_issue_directly(old_rq, &cookie, true);
 			srcu_read_unlock(&data.hctx->queue_rq_srcu, srcu_idx);
 		}
 		goto done;

-- 
Jens Axboe

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly()
  2017-03-14 14:57 [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly() Jens Axboe
@ 2017-03-14 15:17 ` Bart Van Assche
  2017-03-14 15:26   ` Jens Axboe
  2017-03-14 17:48 ` Omar Sandoval
  1 sibling, 1 reply; 5+ messages in thread
From: Bart Van Assche @ 2017-03-14 15:17 UTC (permalink / raw)
  To: Jens Axboe, linux-block

On 03/14/2017 07:57 AM, Jens Axboe wrote:=0A=
> If we have scheduling enabled, we jump directly to insert-and-run.=0A=
> That's fine, but we run the queue async and we don't pass in information=
=0A=
> on whether we can block from this context or not. Fixup both these=0A=
> cases.=0A=
=0A=
How about renaming "can_block" into "may_sleep"? Otherwise this patch=0A=
looks fine to me.=0A=
=0A=
Bart.=0A=

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly()
  2017-03-14 15:17 ` Bart Van Assche
@ 2017-03-14 15:26   ` Jens Axboe
  0 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2017-03-14 15:26 UTC (permalink / raw)
  To: Bart Van Assche, linux-block

On 03/14/2017 09:17 AM, Bart Van Assche wrote:
> On 03/14/2017 07:57 AM, Jens Axboe wrote:
>> If we have scheduling enabled, we jump directly to insert-and-run.
>> That's fine, but we run the queue async and we don't pass in information
>> on whether we can block from this context or not. Fixup both these
>> cases.
> 
> How about renaming "can_block" into "may_sleep"? Otherwise this patch
> looks fine to me.

Sure, either one is fine with me, at least to me they convey the same
information.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly()
  2017-03-14 14:57 [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly() Jens Axboe
  2017-03-14 15:17 ` Bart Van Assche
@ 2017-03-14 17:48 ` Omar Sandoval
  2017-03-14 17:51   ` Jens Axboe
  1 sibling, 1 reply; 5+ messages in thread
From: Omar Sandoval @ 2017-03-14 17:48 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-block

On Tue, Mar 14, 2017 at 08:57:50AM -0600, Jens Axboe wrote:
> If we have scheduling enabled, we jump directly to insert-and-run.
> That's fine, but we run the queue async and we don't pass in information
> on whether we can block from this context or not. Fixup both these
> cases.

Reviewed-by: Omar Sandoval <osandov@fb.com>

Just one question: we call blk_mq_get_driver_tag() with wait=false in
blk_mq_try_issue_directly(). Should we change that to wait=can_block?
Maybe it's pointless to try a direct issue if we'd have to wait for a
tag anyways, though.

> Signed-off-by: Jens Axboe <axboe@fb.com>
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 159187a28d66..4196d6bee92d 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1434,7 +1434,8 @@ static blk_qc_t request_to_qc_t(struct blk_mq_hw_ctx *hctx, struct request *rq)
>  	return blk_tag_to_qc_t(rq->internal_tag, hctx->queue_num, true);
>  }
>  
> -static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie)
> +static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie,
> +				      bool can_block)
>  {
>  	struct request_queue *q = rq->q;
>  	struct blk_mq_queue_data bd = {
> @@ -1475,7 +1476,7 @@ static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie)
>  	}
>  
>  insert:
> -	blk_mq_sched_insert_request(rq, false, true, true, false);
> +	blk_mq_sched_insert_request(rq, false, true, false, can_block);
>  }
>  
>  /*
> @@ -1569,11 +1570,11 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
>  
>  		if (!(data.hctx->flags & BLK_MQ_F_BLOCKING)) {
>  			rcu_read_lock();
> -			blk_mq_try_issue_directly(old_rq, &cookie);
> +			blk_mq_try_issue_directly(old_rq, &cookie, false);
>  			rcu_read_unlock();
>  		} else {
>  			srcu_idx = srcu_read_lock(&data.hctx->queue_rq_srcu);
> -			blk_mq_try_issue_directly(old_rq, &cookie);
> +			blk_mq_try_issue_directly(old_rq, &cookie, true);
>  			srcu_read_unlock(&data.hctx->queue_rq_srcu, srcu_idx);
>  		}
>  		goto done;
> 
> -- 
> Jens Axboe
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly()
  2017-03-14 17:48 ` Omar Sandoval
@ 2017-03-14 17:51   ` Jens Axboe
  0 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2017-03-14 17:51 UTC (permalink / raw)
  To: Omar Sandoval; +Cc: linux-block

On 03/14/2017 11:48 AM, Omar Sandoval wrote:
> On Tue, Mar 14, 2017 at 08:57:50AM -0600, Jens Axboe wrote:
>> If we have scheduling enabled, we jump directly to insert-and-run.
>> That's fine, but we run the queue async and we don't pass in information
>> on whether we can block from this context or not. Fixup both these
>> cases.
> 
> Reviewed-by: Omar Sandoval <osandov@fb.com>
> 
> Just one question: we call blk_mq_get_driver_tag() with wait=false in
> blk_mq_try_issue_directly(). Should we change that to wait=can_block?
> Maybe it's pointless to try a direct issue if we'd have to wait for a
> tag anyways, though.

Exactly, don't want to wait for a tag, at that point we are just
pointlessly stalling an app that could perhaps be submitting more IO.
So I don't think we should factor that in here, better to let the
blocking vs non-blocking drivers behave the same in that regard.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-03-14 17:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-14 14:57 [PATCH] blk-mq-sched: don't run the queue async from blk_mq_try_issue_directly() Jens Axboe
2017-03-14 15:17 ` Bart Van Assche
2017-03-14 15:26   ` Jens Axboe
2017-03-14 17:48 ` Omar Sandoval
2017-03-14 17:51   ` Jens Axboe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.