Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bart.VanAssche@wdc.com (Bart Van Assche)
Subject: [PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE
Date: Mon, 29 Jan 2018 22:22:30 +0000	[thread overview]
Message-ID: <1517264549.2687.59.camel@wdc.com> (raw)
In-Reply-To: <20180129221436.GA6115@redhat.com>

On Mon, 2018-01-29@17:14 -0500, Mike Snitzer wrote:
> On Mon, Jan 29 2018 at  4:51pm -0500,
> Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> 
> > On Mon, 2018-01-29@16:44 -0500, Mike Snitzer wrote:
> > > But regardless of which wins the race, the queue will have been run.
> > > Which is all we care about right?
> > 
> > Running the queue is not sufficient. With this patch applied it can happen
> > that the block driver returns BLK_STS_DEV_RESOURCE, that the two or more
> > concurrent queue runs finish before sufficient device resources are available
> > to execute the request and that blk_mq_delay_run_hw_queue() does not get
> > called at all. If no other activity triggers a queue run, e.g. request
> > completion, this will result in a queue stall.
> 
> If BLK_STS_DEV_RESOURCE is returned then the driver doesn't need to rely
> on a future queue run.  IIUC, that is the entire premise of
> BLK_STS_DEV_RESOURCE.  If the driver had doubt about whether the
> resource were going to be available in the future it should return
> BLK_STS_RESOURCE.
> 
> That may seem like putting a lot on a driver developer (to decide
> between the 2) but I'll again defer to Jens here.  This was the approach
> he was advocating be pursued.

Hello Mike,

There was a typo in my reply: I should have referred to BLK_STS_RESOURCE
instead of BLK_STS_DEV_RESOURCE. The convention for BLK_STS_DEV_RESOURCE is
namely that if .queue_rq() returns that status code that the block driver
guarantees that the queue will be rerun.

Bart.

  reply	other threads:[~2018-01-29 22:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29 20:33 [PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE Mike Snitzer
2018-01-29 21:22 ` Bart Van Assche
2018-01-29 21:44   ` Mike Snitzer
2018-01-29 21:51     ` Bart Van Assche
2018-01-29 22:14       ` Mike Snitzer
2018-01-29 22:22         ` Bart Van Assche [this message]
2018-01-30  5:55         ` [dm-devel] " Ming Lei
2018-01-30  3:20       ` Ming Lei
2018-02-02  0:26       ` [dm-devel] " John Stoffel
2018-02-02  0:53         ` Bart Van Assche
2018-01-30  3:16   ` Ming Lei

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=1517264549.2687.59.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    /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