Linux block layer
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/2] blk-mq-sched: Allocate sched reserved tags as specified in the original queue tagset
Date: Mon, 27 Feb 2017 08:25:20 -0800	[thread overview]
Message-ID: <20170227162520.GC10715@vader> (raw)
In-Reply-To: <353bb44b-7180-7a78-47f5-2ebf03b714bc@kernel.dk>

On Mon, Feb 27, 2017 at 09:15:27AM -0700, Jens Axboe wrote:
> On 02/27/2017 09:10 AM, Sagi Grimberg wrote:
> > 
> >>> Hm, this may fix the crash, but I'm not sure it'll work as intended.
> >>> When we allocate the request, we'll get a reserved scheduler tag, but
> >>> then when we go to dispatch the request and call
> >>> blk_mq_get_driver_tag(), we'll be competing with all of the normal
> >>> requests for a regular driver tag. So maybe on top of this we should add
> >>> the BLK_MQ_REQ_RESERVED flag to the allocation attempt in
> >>> blk_mq_get_driver_tag() if the scheduler tag is reserved? I'm hazy on
> >>> what we expect from reserved tags, so feel free to call me crazy.
> >>
> >> Yeah good point, we need to carry it through. Reserved tags exist
> >> because drivers often need a request/tag for error handling. If all
> >> tags currently are used up for regular IO that is stuck, you need
> >> a reserved tag for error handling to guarantee progress.
> >>
> >> So Sagi's patch does take it half the way there, but get_driver_tag
> >> really needs to know about this as well, or we will just get stuck
> >> there as well. Two solutions, I can think of:
> >>
> >> 1) Check the tag value in get_driver_tag, add BLK_MQ_REQ_RESERVED
> >>    when allocating a driver tag if above X.
> >> 2) Add an RQF_SOMETHING_RESERVED. Add BLK_MQ_REQ_RESERVED in
> >>    get_driver_tag if that is set.
> >>
> >> Comments?
> > 
> > Can't we just not go through the scheduler for reserved tags? Obviously
> > there is no point in scheduling them...
> 
> Right, that would be possible. But I'd rather not treat any requests
> differently, it's a huge pain in the ass that flush request currently
> insert with a driver tag already allocated. So it's not because
> scheduling will add anything at all, it's more that I'd like to move
> flush requests to use regular inserts as well and not deal with some
> request being "special" in any way.
> 
> The below should hopefully work. Totally untested...

I like your variant if it works for Sagi. My only complaint (which was
already there) is that the BUG_ON(tag >= tags->nr_reserved_tags) in
blk_mq_put_tag() looks kind of silly since we just checked that exact
same condition.

> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 54c84363c1b2..e48bc2c72615 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -181,7 +181,7 @@ unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data)
>  void blk_mq_put_tag(struct blk_mq_hw_ctx *hctx, struct blk_mq_tags *tags,
>  		    struct blk_mq_ctx *ctx, unsigned int tag)
>  {
> -	if (tag >= tags->nr_reserved_tags) {
> +	if (!blk_mq_tag_is_reserved(tags, tag)) {
>  		const int real_tag = tag - tags->nr_reserved_tags;
>  
>  		BUG_ON(real_tag >= tags->nr_tags);
> diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
> index 63497423c5cd..5cb51e53cc03 100644
> --- a/block/blk-mq-tag.h
> +++ b/block/blk-mq-tag.h
> @@ -85,4 +85,10 @@ static inline void blk_mq_tag_set_rq(struct blk_mq_hw_ctx *hctx,
>  	hctx->tags->rqs[tag] = rq;
>  }
>  
> +static inline bool blk_mq_tag_is_reserved(struct blk_mq_tags *tags,
> +					  unsigned int tag)
> +{
> +	return tag < tags->nr_reserved_tags;
> +}
> +
>  #endif
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 9611cd9920e9..293e79c1ee95 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -853,6 +853,9 @@ bool blk_mq_get_driver_tag(struct request *rq, struct blk_mq_hw_ctx **hctx,
>  		return true;
>  	}
>  
> +	if (blk_mq_tag_is_reserved(data.hctx->sched_tags, rq->internal_tag))
> +		data.flags |= BLK_MQ_REQ_RESERVED;
> +
>  	rq->tag = blk_mq_get_tag(&data);
>  	if (rq->tag >= 0) {
>  		if (blk_mq_tag_busy(data.hctx)) {
> 
> 
> -- 
> Jens Axboe
> 

  parent reply	other threads:[~2017-02-27 16:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 15:36 [PATCH 1/2] blk-mq-sched: Allocate sched reserved tags as specified in the original queue tagset Sagi Grimberg
2017-02-27 15:36 ` [PATCH 2/2] blk-mq: make sure to back-assign the request to rq_map in blk_mq_alloc_request_hctx Sagi Grimberg
2017-02-27 16:59   ` Omar Sandoval
2017-02-27 17:03     ` Jens Axboe
2017-02-27 17:04       ` Omar Sandoval
2017-02-27 17:06         ` Jens Axboe
2017-02-27 17:26           ` Sagi Grimberg
2017-02-27 15:38 ` [PATCH 1/2] blk-mq-sched: Allocate sched reserved tags as specified in the original queue tagset Jens Axboe
2017-02-27 15:49 ` Omar Sandoval
2017-02-27 15:53   ` Jens Axboe
2017-02-27 16:10     ` Sagi Grimberg
2017-02-27 16:14       ` Omar Sandoval
2017-02-27 16:17         ` Jens Axboe
2017-02-27 16:15       ` Jens Axboe
2017-02-27 16:23         ` Sagi Grimberg
2017-02-27 16:25         ` Omar Sandoval [this message]
2017-02-27 16:27           ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170227162520.GC10715@vader \
    --to=osandov@osandov.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox