From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Cc: "Stefano.Stabellini@eu.citrix.com"
<Stefano.Stabellini@eu.citrix.com>,
"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [RFC v1 0/5] VBD: enlarge max segment per request in blkfront
Date: Fri, 7 Sep 2012 13:49:22 -0400 [thread overview]
Message-ID: <20120907174922.GA13040@phenom.dumpdata.com> (raw)
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
On Thu, Aug 16, 2012 at 10:22:56AM +0000, Duan, Ronghui wrote:
> Hi, list.
> The max segments for request in VBD queue is 11, while for Linux OS/ other VMM, the parameter is set to 128 in default. This may be caused by the limited size of ring between Front/Back. So I guess whether we can put segment data into another ring and dynamic use them for the single request's need. Here is prototype which don't do much test, but it can work on Linux 64 bits 3.4.6 kernel. I can see the CPU% can be reduced to 1/3 compared to original in sequential test. But it bring some overhead which will make random IO's cpu utilization increase a little.
>
> Here is a short version data use only 1K random read and 64K sequential read in direct mode. Testing a physical SSD disk as blkback in backend. CPU% is got form xentop.
> Read 1K random IOPS Dom0 CPU DomU CPU%
> W 52005.9 86.6 71
> W/O 52123.1 85.8 66.9
So I am getting some different numbers. I tried a simple 4K read:
[/dev/xvda1]
bssplit=4K
rw=read
direct=1
size=4g
ioengine=libaio
iodepth=64
And with your patch got:
read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
without:
read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
>
> Read 64K seq BW MB/s Dom0 CPU DomU CPU%
> W 250 27.1 10.6
> W/O 250 62.6 31.1
Hadn't tried that yet.
next prev parent reply other threads:[~2012-09-07 17:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 10:22 [RFC v1 0/5] VBD: enlarge max segment per request in blkfront Duan, Ronghui
2012-08-16 11:14 ` Jan Beulich
2012-08-17 1:12 ` Duan, Ronghui
2012-08-16 13:34 ` Konrad Rzeszutek Wilk
2012-08-16 13:55 ` Konrad Rzeszutek Wilk
2012-08-17 1:26 ` Duan, Ronghui
2012-08-16 14:18 ` Jan Beulich
2012-09-07 17:49 ` Konrad Rzeszutek Wilk [this message]
2012-09-13 2:28 ` Duan, Ronghui
2012-09-13 7:32 ` Jan Beulich
2012-09-13 11:05 ` Stefano Stabellini
2012-09-13 13:23 ` Konrad Rzeszutek Wilk
2012-09-13 14:05 ` Duan, Ronghui
2012-09-17 6:33 ` Duan, Ronghui
2012-09-17 14:37 ` Konrad Rzeszutek Wilk
2012-09-19 21:11 ` Konrad Rzeszutek Wilk
2012-09-13 13:21 ` Konrad Rzeszutek Wilk
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=20120907174922.GA13040@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=ronghui.duan@intel.com \
--cc=xen-devel@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;
as well as URLs for NNTP newsgroup(s).