linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 04/10] blk-mq: kill undead requests during CPU hotplug notify
Date: Mon, 28 Sep 2015 19:46:48 +0200	[thread overview]
Message-ID: <20150928174648.GA2136@lst.de> (raw)
In-Reply-To: <alpine.LNX.2.00.1509281709460.23840@localhost.lm.intel.com>

On Mon, Sep 28, 2015@05:39:47PM +0000, Keith Busch wrote:
> The command is still owned by the device and breaks if the controller
> happens to complete the command after a cpu hot event. This was 'ok'
> when the driver provided special completion handling.
>
> We'd have to reset the controller to reliably recover the command,
> but that's a bit heavy handed.

My impression was that's it's flakey to broken already and we don't
change that situation.  With my changes we'll mark it as completed
and if the command comes in during the small hotplug CPU window the
completion handler will see it already completed and ignore the
actual hardware completion.

Now this relies on the subtile fact that nvmeq->tags doesn't change
during CPU hotplug, which it currently doesn't.  That's probably wrong to
start with for other reasons, but I'd like to untangle that whole
mess one at a time.  We'll probably need to move to a model where
multiple request_queues share the hw_ctx structures to sort that
out properly.

  reply	other threads:[~2015-09-28 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27 19:01 nvme completion path optimizations and fixes V2 Christoph Hellwig
2015-09-27 19:01 ` [PATCH 01/10] blk-mq: avoid setting hctx->tags->cpumask before allocation Christoph Hellwig
2015-09-27 19:01 ` [PATCH 02/10] blk-mq: fix racy updates of rq->errors Christoph Hellwig
2015-10-01  7:59   ` Christoph Hellwig
2015-10-01  8:12     ` Jens Axboe
2015-09-27 19:01 ` [PATCH 03/10] blk-mq: factor out a helper to iterate all tags for a request_queue Christoph Hellwig
2015-09-27 19:01 ` [PATCH 04/10] blk-mq: kill undead requests during CPU hotplug notify Christoph Hellwig
2015-09-28 17:39   ` Keith Busch
2015-09-28 17:46     ` Christoph Hellwig [this message]
2015-09-28 18:15       ` Keith Busch
2015-10-01  7:39         ` Christoph Hellwig
2015-09-27 19:01 ` [PATCH 05/10] nvme: switch AEN processing to use blk_execute_rq_nowait Christoph Hellwig
2015-09-27 19:01 ` [PATCH 06/10] nvme: switch delete SQ/CQ to blk_execute_rq_nowait Christoph Hellwig
2015-09-27 19:01 ` [PATCH 07/10] nvme: switch abort " Christoph Hellwig
2015-09-27 19:01 ` [PATCH 08/10] nvme: simplify completion handling Christoph Hellwig
2015-09-27 19:01 ` [PATCH 09/10] nvme: properly free resources for cancelled command Christoph Hellwig
2015-09-27 19:01 ` [PATCH 10/10] nvme: micro optimize nvme_submit_priv Christoph Hellwig

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=20150928174648.GA2136@lst.de \
    --to=hch@lst.de \
    /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;
as well as URLs for NNTP newsgroup(s).