From: Keith Busch <keith.busch@intel.com>
To: Benoit Depail <benoit.depail@nbs-system.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
xen-users@lists.xen.org, WebDawg <webdawg@gmail.com>,
linux-block@vger.kernel.org
Subject: Re: [Xen-users] File-based domU - Slow storage write since xen 4.8
Date: Fri, 21 Jul 2017 11:53:33 -0400 [thread overview]
Message-ID: <20170721155333.GG1202@localhost.localdomain> (raw)
In-Reply-To: <3443d6ac-9011-85fb-3613-bacdee184fcc@nbs-system.com>
On Fri, Jul 21, 2017 at 12:19:39PM +0200, Benoit Depail wrote:
> On 07/20/17 19:36, Keith Busch wrote:
> >
> > As a test, could you throttle the xvdb queue's max_sectors_kb? If I
> > followed xen-blkfront correctly, the default should have it set to 44.
> > Try setting it to 40.
> >
> > echo 40 > /sys/block/xvdb/queue/max_sectors_kb
> >
>
> The default value on my domU is 128.
>
> I ran a couple of tests with different values, starting from 40 and up
> to 128, clearing the cache between each tests.
>
> The only value that showed the issue is 128. Even setting max_sectors_kb
> to 127 is enough to get normal behaviour.
Ok, I don't quite follow how it's initialized to 128k, but your
results appear to confirm the default settings are not optimal for the
interface. The patch you identified just submits commands to the max
size the driver asked to use. If the largest size tanks performance,
I think xen-blkfront should register a smaller transfer size, or maybe
some other constraint needs to be refined.
Roger,
I'm a bit out of my depth here in the xen code. Is this something you
may be able to help clarify?
Thanks,
Keith
next prev parent reply other threads:[~2017-07-21 15:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5554bd39-6e0a-5c17-2b64-bb80d4a6502b@nbs-system.com>
[not found] ` <CAKdd5H9f_=NCYMmhLcvHKFw7m_sKvygSVqz3+Z0YPAGiPMxKxQ@mail.gmail.com>
[not found] ` <5b562ef2-36e2-a08e-1683-6ffc7cfa54de@nbs-system.com>
[not found] ` <20170717124931.rsiqxkzzkmvfofd7@MacBook-Pro-de-Roger.local>
[not found] ` <5dd18982-cbcf-a675-1e07-5b4c4e4da50e@nbs-system.com>
[not found] ` <20170717164658.drliebetcnil3wjb@dhcp-3-128.uk.xensource.com>
[not found] ` <bba4e389-b975-fbb8-b680-c9c4039617ca@nbs-system.com>
2017-07-20 8:52 ` [Xen-users] File-based domU - Slow storage write since xen 4.8 Roger Pau Monné
2017-07-20 15:12 ` Benoit Depail
2017-07-20 15:33 ` Keith Busch
2017-07-20 15:57 ` Benoit Depail
2017-07-20 17:36 ` Keith Busch
2017-07-21 10:19 ` Benoit Depail
2017-07-21 15:53 ` Keith Busch [this message]
2017-07-21 16:07 ` Roger Pau Monné
2017-07-21 17:07 ` Benoit Depail
2017-07-25 22:25 ` Keith Busch
2017-07-28 14:50 ` Benoit Depail
2017-08-01 9:48 ` Roger Pau Monné
2017-08-02 16:29 ` Benoit Depail
2017-08-23 15:54 ` Benoit Depail
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=20170721155333.GG1202@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=benoit.depail@nbs-system.com \
--cc=linux-block@vger.kernel.org \
--cc=roger.pau@citrix.com \
--cc=webdawg@gmail.com \
--cc=xen-users@lists.xen.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