From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Performance
Date: Wed, 18 Jan 2017 23:41:22 +0000 [thread overview]
Message-ID: <1484782880.2822.24.camel@intel.com> (raw)
In-Reply-To: 1481043483.4630.51.camel@intel.com
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Tue, 2016-12-06 at 16:58 +0000, Walker, Benjamin wrote:
> On Tue, 2016-12-06 at 16:35 +0000, Harris, James R wrote:
> >
> > > On Dec 6, 2016, at 5:49 AM, Kumaraparameshwaran Rathnavel <krath@
> > > cloudsimple
> > > .com> wrote:
> > >
> > > The setup is the default setup of NVMf target with Direct
> > > attached
> > > Subsystem. The FIO plugin was at the target side and the IOPS
> > > from SPDK was
> > > found to be around 2.5K and the IOPS from kernel was found to be
> > > 100k.
> >
> >
> > Hi Param,
> >
> > Can you check the AcceptorPollRate setting in your configuration
> > file? There
> > was a recent fix to the default value for this parameter. You
> > should set it
> > to at least 10000 (10ms).
> >
> > https://github.com/spdk/spdk/commit/5f3761cf7ec50cf03183203dc50657a
> > 9f2a18908
> >
> > Thanks,
>
> Just to reinforce here - this is the solution. We saw this internally
> a few
> weeks ago. Increasing the AcceptorPollRate to at least 10ms (you can
> go as much
> as 1 second if you want, but the performance benefit decreases the
> larger you
> make it), or moving the accceptor to a different core using the
> AcceptorCore
> option will fix the problem.
To follow up on this - we've now root caused exactly why our acceptor
polling function was slowing down the system so much. Before, I had
suggested polling less often or doing the polling on a separate core.
After these two commits
https://github.com/spdk/spdk/commit/d2c0feac8a13944bc9af7c60ed047809cf1f5d9dhttps://github.com/spdk/spdk/commit/4a95a81e694c4f58031b181a6127583d6f55483e
that is no longer necessary. Any remotely reasonable value for AcceptorPollRate
and placing the Acceptor on any core will now yield excellent performance
results with SPDK.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3274 bytes --]
next reply other threads:[~2017-01-18 23:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 23:41 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-12-07 1:22 [SPDK] Performance Yang, Ziye
2016-12-06 16:58 Walker, Benjamin
2016-12-06 16:35 Harris, James R
2016-12-06 13:20 Andrey Kuzmin
2016-12-06 13:08 Kumaraparameshwaran Rathnavel
2016-12-06 13:05 Andrey Kuzmin
2016-12-06 12:57 Kumaraparameshwaran Rathnavel
2016-12-06 12:54 Andrey Kuzmin
2016-12-06 12:49 Kumaraparameshwaran Rathnavel
2016-12-06 12:27 Andrey Kuzmin
2016-12-06 12:24 Kumaraparameshwaran Rathnavel
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=1484782880.2822.24.camel@intel.com \
--to=spdk@lists.01.org \
/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