From: willy@linux.intel.com (Matthew Wilcox)
Subject: Version 0.8 uploaded
Date: Wed, 11 Jan 2012 09:50:02 -0500 [thread overview]
Message-ID: <20120111145002.GY14291@linux.intel.com> (raw)
I've just pushed out version 0.8 of the driver. Here's the shortlog:
Matthew Wilcox (13):
NVMe: Implement doorbell stride capability
NVMe: Update Identify Controller data structure
NVMe: Simplify completion handling
NVMe: Change get_nvmeq to take a dev instead of a namespace
NVMe: Change nvme_completion_fn to take a dev
NVMe: Merge the nvme_bio and nvme_prp data structures
NVMe: Rename IO_TIMEOUT to NVME_IO_TIMEOUT
NVMe: Fix DMA mapping for admin commands
NVMe: Mark the end of the sg list
NVMe: Simplify nvme_unmap_user_pages
NVMe: Set queue flags correctly
NVMe: Version 0.8
NVMe: Set number of queues correctly
Mostly bugfixes, but the big change is merging the nvme_bio and nvme_prp
data structures. I've been made aware that certain applications mostly
send I/Os larger than a single page; in particular MySQL uses 16k I/Os.
That was probably the pessimal size for the NVMe driver; just large
enough to cause it to allocate an nvme_prp data structure and small
enough that per-I/O overhead is still meaningful.
So I merged the nvme_bio and nvme_prp data structures into the new
nvme_iod data structure. This was a bit of a challenge since it needs
to contain two variable-length arrays, which C does not permit you to
express neatly. I hope the comments around the data structure make it
clear what I'm doing. I saw noticable reductions in per-I/O CPU overhead
with the new scheme, so I think it's worthwhile. Also, the additional
overhead for 512-byte I/Os was down in the noise and it was completely
unmeasurable for 4k I/Os.
I plan to ask Linus to merge this version of the driver for Linux 3.3.
I know there's still a lot on the TODO list, but we'll have a chance to
merge more patches in April. I have a couple of patches from Keith Busch
still to review (adding a character device to represent the controller
and the beginnings of an error handler), but I'd rather get what we have
merged now than wait for the next merge window.
reply other threads:[~2012-01-11 14:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20120111145002.GY14291@linux.intel.com \
--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 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).