From: Keith Busch <keith.busch@intel.com>
To: Alana Alexander-Rutledge <Alana.Alexander-Rutledge@microsemi.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Stephen Bates <stephen.bates@microsemi.com>
Subject: Re: Higher block layer latency in kernel v4.8-r6 vs. v4.4.16 for NVMe
Date: Thu, 10 Nov 2016 14:04:48 -0500 [thread overview]
Message-ID: <20161110190447.GD4929@localhost.localdomain> (raw)
In-Reply-To: <33507ACF7FF43A4FBE532BA768AFA4243AF0BECC@avsrvexchmbx1.microsemi.net>
On Wed, Nov 09, 2016 at 01:43:55AM +0000, Alana Alexander-Rutledge wrote:
> Hi,
>
> I have been profiling the performance of the NVMe and SAS IO stacks on Linux. I used blktrace and blkparse to collect block layer trace points and a custom analysis script on the trace points to average out the latencies of each trace point interval of each IO.
>
> I started with Linux kernel v4.4.16 but then switched to v4.8-r6. One thing that stood out is that for measurements at queue depth = 1, the average Q2D latency was quite a bit higher in the NVMe path with the newer version of the kernel.
>
> The Q, G, I, and D below refer to blktrace/blkparse trace points (queued, get request, inserted, and issued).
>
> Queue Depth = 1
> Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
> Q2G 0.212 0.573
> G2I 0.944 1.507
> I2D 0.435 0.837
> Q2D 1.592 2.917
>
> For other queue depths, Q2D was similar for both versions of the kernel.
>
> Queue Depth Average Q2D - v4.4.16 (us) Average Q2D - v4.8-rc6 (us)
> 2 1.893 1.736
> 4 1.289 1.38
> 8 1.223 1.162
> 16 1.14 1.178
> 32 1.007 1.425
> 64 0.964 0.978
> 128 0.915 0.941
>
> I did not see this as a problem with the 12G SAS SSD that I measured.
>
> Queue Depth = 1
> Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
> Q2G 0.264 0.301
> G2I 0.917 0.864
> I2D 0.432 0.397
> Q2D 1.613 1.561
>
> Is this a known change or do you know what the reason for this is?
Are you using blk-mq for the 12G SAS? I assume not since most of these
intervals would have executed through the same code path and shouldn't
show a difference from to the underlying driver.
My guess for at least part of the additional latency to D/issued, the nvme
driver in 4.1 used to call blk_mq_start_request (marks the "issued" trace
point) before it constructed the nvme command. 4.8 calls it after.
Have you noticed a difference in over-all latency?
next prev parent reply other threads:[~2016-11-10 18:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 1:43 Higher block layer latency in kernel v4.8-r6 vs. v4.4.16 for NVMe Alana Alexander-Rutledge
2016-11-10 19:04 ` Keith Busch [this message]
2016-11-10 22:14 ` Alana Alexander-Rutledge
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=20161110190447.GD4929@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=Alana.Alexander-Rutledge@microsemi.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=stephen.bates@microsemi.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).