All of lore.kernel.org
 help / color / mirror / Atom feed
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?

WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@intel.com (Keith Busch)
Subject: 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@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?

  reply	other threads:[~2016-11-10 18:53 UTC|newest]

Thread overview: 6+ 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-09  1:43 ` Alana Alexander-Rutledge
2016-11-10 19:04 ` Keith Busch [this message]
2016-11-10 19:04   ` Keith Busch
2016-11-10 22:14   ` Alana Alexander-Rutledge
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 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.