From: Keith Busch <keith.busch@intel.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: linux-block@vger.kernel.org, Jens Axboe <axboe@fb.com>,
Marc MERLIN <marc@merlins.org>, Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCHv2 2/2] nvme: Complete all stuck requests
Date: Mon, 27 Feb 2017 10:01:08 -0500 [thread overview]
Message-ID: <20170227150107.GA5789@localhost.localdomain> (raw)
In-Reply-To: <b66a614e-140e-86e9-56bf-d3eafb750aa5@grimberg.me>
On Mon, Feb 27, 2017 at 03:46:09PM +0200, Sagi Grimberg wrote:
> On 24/02/17 02:36, Keith Busch wrote:
> > If the block layer has entered requests and gets a CPU hot plug event
> > prior to the resume event, it will wait for those requests to exit. If
> > the nvme driver is shutting down, it will not start the queues back up,
> > preventing forward progress.
> >
> > To fix that, this patch freezes the request queues when the driver intends
> > to shut down the controller so that no new requests may enter. After the
> > controller has been disabled, the queues will be restarted to force all
> > entered requests to end in failure so that blk-mq's hot cpu notifier may
> > progress. To ensure the queue usage count is 0 on a shutdown, the driver
> > waits for freeze to complete before completing the controller shutdown.
>
> Keith, can you explain (again) for me why is the freeze_wait must happen
> after the controller has been disabled, instead of starting the queues
> and waiting right after freeze start?
Yeah, the driver needs to make forward progress even if the controller
isn't functioning. If we do the freeze wait before disabling the
controller, there's no way to reclaim missing completions. If the
controller is working perfectly, it'd be okay, but the driver would be
stuck if there's a problem.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2017-02-27 15:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 0:36 [PATCHv2 1/2] blk-mq: Export blk_mq_freeze_queue_wait Keith Busch
2017-02-24 0:36 ` [PATCHv2 2/2] nvme: Complete all stuck requests Keith Busch
2017-02-24 6:50 ` Christoph Hellwig
2017-02-27 13:46 ` Sagi Grimberg
2017-02-27 15:01 ` Keith Busch [this message]
2017-02-27 17:27 ` Sagi Grimberg
2017-02-27 19:15 ` Keith Busch
2017-02-28 7:42 ` Artur Paszkiewicz
2017-02-28 11:45 ` Sagi Grimberg
2017-02-28 16:57 ` Keith Busch
2017-03-01 8:54 ` Artur Paszkiewicz
2017-02-24 6:49 ` [PATCHv2 1/2] blk-mq: Export blk_mq_freeze_queue_wait Christoph Hellwig
2017-02-27 13:38 ` Sagi Grimberg
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=20170227150107.GA5789@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=marc@merlins.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;
as well as URLs for NNTP newsgroup(s).