From: jonathan.derrick@intel.com (Jon Derrick)
Subject: [PATCH 0/3] NVMe: Introduce CMB allocation scheme
Date: Tue, 12 Jan 2016 17:27:41 -0700 [thread overview]
Message-ID: <20160113002741.GA6841@localhost.localdomain> (raw)
In-Reply-To: <20160113000838.GA5803@localhost.localdomain>
On Wed, Jan 13, 2016@12:08:39AM +0000, Keith Busch wrote:
> 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.
>
Yep. I noticed the same thing today. It works coinicidentally -if- the
depth remains the same before and after CMB allocation.
> 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.
I've cleaned up the nvme-side depth dependencies but still don't have
anything to modify the hardware contexts. I'll take a look at your patch
in the next couple of days.
prev parent reply other threads:[~2016-01-13 0:27 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
2016-01-13 0:27 ` Jon Derrick [this message]
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=20160113002741.GA6841@localhost.localdomain \
--to=jonathan.derrick@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.