From: axboe@fb.com (Jens Axboe)
Subject: [PATCH v7] NVMe: conversion to blk-mq
Date: Fri, 13 Jun 2014 15:28:58 -0600 [thread overview]
Message-ID: <539B6D1A.3010602@fb.com> (raw)
In-Reply-To: <alpine.LRH.2.03.1406131307330.4699@AMR>
On 06/13/2014 01:22 PM, Keith Busch wrote:
> One performance oddity we observe is that servicing the interrupt on the
> thread sibling of the core that submitted the I/O is the worst performing
> cpu you can chose; it's actually better to use a different core on the
> same node. At least that's true as long as you're not utilizing the cpus
> for other work, so YMMV.
This doesn't match what I see here. Just ran some test cases - both
sync, and higher QD. For sync performance, core or thread sibling is the
best choice, other CPUs next. That is pretty logical.
For a more loaded run, thread sibling ends up being a better choice than
core, since core runs out of steam (255K vs 275K here). And thread
sibling is still a marginally better choice than some other core on the
same node.
Which pretty much matches my expectations of what the best mappings
would be.
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@fb.com>
To: Keith Busch <keith.busch@intel.com>
Cc: "Matias Bjørling" <m@bjorling.me>,
"Matthew Wilcox" <willy@linux.intel.com>,
"sbradshaw@micron.com" <sbradshaw@micron.com>,
"tom.leiming@gmail.com" <tom.leiming@gmail.com>,
"hch@infradead.org" <hch@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH v7] NVMe: conversion to blk-mq
Date: Fri, 13 Jun 2014 15:28:58 -0600 [thread overview]
Message-ID: <539B6D1A.3010602@fb.com> (raw)
In-Reply-To: <alpine.LRH.2.03.1406131307330.4699@AMR>
On 06/13/2014 01:22 PM, Keith Busch wrote:
> One performance oddity we observe is that servicing the interrupt on the
> thread sibling of the core that submitted the I/O is the worst performing
> cpu you can chose; it's actually better to use a different core on the
> same node. At least that's true as long as you're not utilizing the cpus
> for other work, so YMMV.
This doesn't match what I see here. Just ran some test cases - both
sync, and higher QD. For sync performance, core or thread sibling is the
best choice, other CPUs next. That is pretty logical.
For a more loaded run, thread sibling ends up being a better choice than
core, since core runs out of steam (255K vs 275K here). And thread
sibling is still a marginally better choice than some other core on the
same node.
Which pretty much matches my expectations of what the best mappings
would be.
next prev parent reply other threads:[~2014-06-13 21:28 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 9:20 [PATCH v7] conversion to blk-mq Matias Bjørling
2014-06-10 9:20 ` Matias Bjørling
2014-06-10 9:20 ` [PATCH v7] NVMe: " Matias Bjørling
2014-06-10 9:20 ` Matias Bjørling
2014-06-10 15:51 ` Keith Busch
2014-06-10 15:51 ` Keith Busch
2014-06-10 16:19 ` Jens Axboe
2014-06-10 16:19 ` Jens Axboe
2014-06-10 19:29 ` Keith Busch
2014-06-10 19:29 ` Keith Busch
2014-06-10 19:58 ` Jens Axboe
2014-06-10 19:58 ` Jens Axboe
2014-06-10 21:10 ` Keith Busch
2014-06-10 21:10 ` Keith Busch
2014-06-10 21:14 ` Jens Axboe
2014-06-10 21:14 ` Jens Axboe
2014-06-10 21:21 ` Keith Busch
2014-06-10 21:21 ` Keith Busch
2014-06-10 21:33 ` Matthew Wilcox
2014-06-10 21:33 ` Matthew Wilcox
2014-06-11 16:54 ` Jens Axboe
2014-06-11 16:54 ` Jens Axboe
2014-06-11 17:09 ` Matthew Wilcox
2014-06-11 17:09 ` Matthew Wilcox
2014-06-11 22:22 ` Matias Bjørling
2014-06-11 22:22 ` Matias Bjørling
2014-06-11 22:51 ` Keith Busch
2014-06-11 22:51 ` Keith Busch
2014-06-12 14:32 ` Matias Bjørling
2014-06-12 14:32 ` Matias Bjørling
2014-06-12 16:24 ` Keith Busch
2014-06-12 16:24 ` Keith Busch
2014-06-13 0:06 ` Keith Busch
2014-06-13 0:06 ` Keith Busch
2014-06-13 14:07 ` Jens Axboe
2014-06-13 14:07 ` Jens Axboe
2014-06-13 15:05 ` Keith Busch
2014-06-13 15:05 ` Keith Busch
2014-06-13 15:11 ` Jens Axboe
2014-06-13 15:11 ` Jens Axboe
2014-06-13 15:16 ` Keith Busch
2014-06-13 15:16 ` Keith Busch
2014-06-13 18:14 ` Jens Axboe
2014-06-13 18:14 ` Jens Axboe
2014-06-13 19:22 ` Keith Busch
2014-06-13 19:22 ` Keith Busch
2014-06-13 19:29 ` Jens Axboe
2014-06-13 19:29 ` Jens Axboe
2014-06-13 20:56 ` Jens Axboe
2014-06-13 20:56 ` Jens Axboe
2014-06-13 21:28 ` Jens Axboe [this message]
2014-06-13 21:28 ` 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=539B6D1A.3010602@fb.com \
--to=axboe@fb.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.