From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roberto Scudeller <beto.rvs@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: why do I get bad disk write performance in the kernel 3.1?
Date: Wed, 9 Nov 2011 22:42:37 -0500 [thread overview]
Message-ID: <20111110034237.GA3156@phenom.dumpdata.com> (raw)
In-Reply-To: <CAOdhohc+UoicOGTW2W_rzdf7d4RR48QyOb4dr=f2g-LAWKB-dA@mail.gmail.com>
On Wed, Nov 09, 2011 at 02:52:59PM -0200, Roberto Scudeller wrote:
> Konrad,
>
> Thanks for help.
OK, so looks like you are using qdisk. Can you try creating an
LVM and blasting the image onto that?
And obviously then using 'phy:/dev/vg_guest/...' ?
You could also try the 'file:/local-disk' which will setup a loopback device
and use that. Try that as well.
>
> My windows.cfg is:
> name='benchCM-windows-2003-64b-std-test'
> kernel='/usr/lib/xen/boot/hvmloader'
> builder='hvm'
> memory=512
> vcpus=2
> pae=1
> acpi=1
> apic=1
> disk=[ 'tap2:aio:/local-disk/benchCM-windows-2003-64b-std/xvda,xvda,w' ]
> device_model='/usr/lib/xen/bin/qemu-dm'
> boot='c'
> sdl=0
> vnc=1
> vncunused=1
> vnclisten='0.0.0.0'
> vncpasswd=''
> stdvga=0
> extra=''
> on_reboot='restart'
> on_shutdown='destroy'
> ramdisk=''
> image_name=''
> on_crash='destroy'
> bootloader=''
> root=''
> platform='xen'
> network_mode='tap'
> usb = 1
> usbdevice = 'tablet'
>
> The xvda disk is a raw disk, created with dd.
> I use the windows.cfg in both kernel.
>
>
>
> 2011/11/9 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> > On Wed, Nov 09, 2011 at 12:58:27PM -0200, Roberto Scudeller wrote:
> > > Hi all,
> > >
> > > I'm testing the new kernel 3.1 from kernel.org, and xen 4.1.2-rc1-pre.
> > > I execute a CrystalMark IO Benchmark, in windows 2003 VM with gplpv
> > > drivers, and receive an amazing result for reading, but the write numbers
> > > are very disappointing.
> > >
> > > I run the VM in local disk, and receive these numbers:
> > > Seq read: 244 MB/s
> > > 512K read: 239 MB/s
> > > 4K read: 27 MB/s
> > > 4K QD 32: 90 MB/s
> > >
> > > Seq write: 20 MB/s
> > > 512K: 20 MB/s
> > > 4K: 8 MB/s
> > > 4K QD 32: 12MB/s
> > >
> > > In older kernel, 2.6.32.x:
> > > Seq read: 189 MB/s
> > > 512K read: 169 MB/s
> > > 4K read: 11 MB/s
> > > 4K QD 32: 34 MB/s
> > >
> > > Seq write: 177 MB/s
> > > 512K: 166 MB/s
> > > 4K: 12 MB/s
> > > 4K QD 32: 36 MB/s
> > >
> > > Could anyone help me. Why is the new kernel faster in reading, but too
> > slow
> > > writing ?
> >
> > It would help if you gave an idea of what the guest configuration is and
> > what is the backend. It might be that the backend you are using in 3.1 is
> > QEMU qdisk, not xen-blkback.
> >
>
>
>
> --
> Roberto Scudeller
next prev parent reply other threads:[~2011-11-10 3:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 14:58 why do I get bad disk write performance in the kernel 3.1? Roberto Scudeller
2011-11-09 15:18 ` Konrad Rzeszutek Wilk
2011-11-09 16:52 ` Roberto Scudeller
2011-11-09 17:14 ` Roberto Scudeller
2011-11-10 3:42 ` Konrad Rzeszutek Wilk [this message]
2011-11-10 9:24 ` Ian Campbell
2011-11-10 14:25 ` Roberto Scudeller
2011-11-10 14:29 ` Ian Campbell
-- strict thread matches above, loose matches on Subject: below --
2012-01-18 12:46 Norbert Marx
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=20111110034237.GA3156@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=beto.rvs@gmail.com \
--cc=xen-devel@lists.xensource.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.