From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH 0/3] NVMe: Introduce CMB allocation scheme
Date: Wed, 13 Jan 2016 00:08:39 +0000 [thread overview]
Message-ID: <20160113000838.GA5803@localhost.localdomain> (raw)
In-Reply-To: <20160106201308.GB21311@localhost.localdomain>
On Wed, Jan 06, 2016@08:13:08PM +0000, Keith Busch wrote:
> On Wed, Dec 30, 2015@10:47:56AM -0700, Jon Derrick wrote:
> > This patchset changes the CMB allocation scheme. Instead of reserving
> > the entire range for SQes and automatically placing the SQes in the CMB,
> > this set creates sysfs knobs to manage it. This allows partial usage of
> > the CMB for SQes, so that the remainder can be mmapped or used for other
> > NVMe-defined CMB usages.
>
> Thanks, Jon.
>
> In general, I like the control and visibility this provides. With this,
> I think we're on the verge of warranting a new drivers/nvme/host/sysfs.c
> file to keep all the nvme sysfs management in one place.
>
> I don't think anyone is in a rush to see this in the 4.5 merge window,
> so I'll load this on a CMB capable machine and provide a more thorough
> review in the next week or so.
One potential problem, this allows the queue depth to change on a live
request_queue. The block layer won't allow that right now. That can
also theoretically happen on a controller reset, but doesn't happen in
real life (that I know of). For this CMB proposal to really be useful,
we need a new blk-mq API to let us change the depth at runtime.
I thought the dynamic h/w contexts patch[1] was 'ok' and may have
provided a route to change the depth as well. That patch, though, saw a
0-day boot failure. The failure was incorrectly sent to my spam folder,
and I only noticed it this week. If that can be acceptably resolved,
then it looks possible to alter the queue depth with a bit more work.
---
[1] http://lists.infradead.org/pipermail/linux-nvme/2015-December/003452.html
next prev parent reply other threads:[~2016-01-13 0:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 17:47 [PATCH 0/3] NVMe: Introduce CMB allocation scheme Jon Derrick
2015-12-30 17:47 ` [PATCH 1/3] NVMe: Introduce sysfs entries for submission queues in CMB Jon Derrick
2015-12-30 17:47 ` [PATCH 2/3] NVMe: Generate resource tree for CMB Jon Derrick
2015-12-30 20:59 ` Jon Derrick
2015-12-30 17:47 ` [PATCH 3/3] NVMe: Create CMB resource sysfs file Jon Derrick
2016-01-06 20:13 ` [PATCH 0/3] NVMe: Introduce CMB allocation scheme Keith Busch
2016-01-06 21:24 ` Stephen Bates
2016-01-13 0:08 ` Keith Busch [this message]
2016-01-13 0:27 ` Jon Derrick
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=20160113000838.GA5803@localhost.localdomain \
--to=keith.busch@intel.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 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.