From: willy@linux.intel.com (Matthew Wilcox)
Subject: [PATCH] NVMe: Add rw_page support
Date: Fri, 14 Nov 2014 10:52:23 -0500 [thread overview]
Message-ID: <20141114155223.GG11522@wil.cx> (raw)
In-Reply-To: <54661AC5.7000605@kernel.dk>
On Fri, Nov 14, 2014@08:07:49AM -0700, Jens Axboe wrote:
> On 11/14/2014 07:58 AM, Matthew Wilcox wrote:
> > On Thu, Nov 13, 2014@06:29:37PM -0700, Jens Axboe wrote:
> >> The downside I see is that this is an OOB IO path. Once we start adding IO
> >> scheduling for those that need that, then this will completely bypass that.
> >
> > The idea is that you would only enable it for devices that are based on
> > NVM that is of "near-DRAM" speeds, and can complete small I/Os as fast
> > as they are issued. For those kinds of devices, there is absolutely no
> > value to any kind of IO scheduling.
>
> I agree, that's not the kind of device that people would generally do
> scheduling on, and we can't at those rates. But if that's the case, why
> isn't this a sync interface? "Near DRAM speeds" and interrupt driven
> seems like a poor choice.
It could be done as a sync interface; zram and brd do implement it
synchronously. But if you look at the callers, mostly they try to send
several pages before waiting on each of them to complete, and so we can
overlap the work of sending each page with the drive handling the I/O
of the previous page. You'll notice that we check the completion queue
before returning from nvme_rw_page(), so not waiting for an interrupt
to fire for anything that already completed.
The missing piece that I think we need is something like the
patch I sent last year to spin instead of sleeping in io_schedule()
(https://lwn.net/Articles/555886/). That will ensure that we pick up
the last I/O or two without waiting for an interrupt.
next prev parent reply other threads:[~2014-11-14 15:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 0:05 [PATCH] NVMe: Add rw_page support Keith Busch
2014-11-14 1:29 ` Jens Axboe
2014-11-14 14:58 ` Matthew Wilcox
2014-11-14 15:07 ` Jens Axboe
2014-11-14 15:52 ` Matthew Wilcox [this message]
2014-11-14 16:32 ` Jens Axboe
2014-11-14 17:05 ` Keith Busch
2014-11-14 20:53 ` Jens Axboe
2014-11-14 22:59 ` Keith Busch
2014-11-14 14:55 ` Matthew Wilcox
[not found] ` <CANvN+ekQTdNgPe33iaM_9=2Hjrfds2B2R3d3XK06K9n=SY+ZKA@mail.gmail.com>
2014-11-14 22:50 ` Keith Busch
2014-11-14 22:56 ` Jens Axboe
2014-11-14 23:04 ` Keith Busch
2014-11-14 23:30 ` Jens Axboe
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=20141114155223.GG11522@wil.cx \
--to=willy@linux.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.