From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ronny Hegewald <ronny.hegewald@online.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: bad write performance with qdisk with larger files in pv-domU
Date: Fri, 3 Jun 2011 19:16:39 -0400 [thread overview]
Message-ID: <20110603231639.GA21830@dumpdata.com> (raw)
In-Reply-To: <201106032349.47095.ronny.hegewald@online.de>
On Fri, Jun 03, 2011 at 11:49:47PM +0000, Ronny Hegewald wrote:
> Im using the following 32-bit setup:
>
> - xen 4.1.0
> - upstream linux-kernel 2.6.39 as dom0
> - linux 2.6.32 pv-domU that has several ext3 partitions mounted with qdisk
> (same behaviour with a 2.6.39 kernel, so i continued the investigation with
> the 2.6.32er kernel)
>
> Die read performance is good (ca. 60 MB/s)
>
> For smaller files (< 30-40 MB) the write-speed is ok.
>
> But if i copy a larger file (ca > 40 MB), the write speed decreases to ca. 0,5
> MB/s, after the first ca. 40 MBs are written.
>
> One reason for the bad performance might be that qdisk doesnt use AIO. For
> testing purposes i activated AIO in hw/xen_disk.c (i set use_aio=1), but the
> domU freezed shortly after the domU-kernel started.
You could also use this patch:
http://darnok.org/xen/qdisk_vs_blkback_v3.1/qemu-enable-aio.patch
But why not use the 3.0-rc1 with the xen-blkback? Or if you want to use 2.6.39
you could use the
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/2.6.39.x
tree
>
> Is this performance-impact expected when no AIO is used?
Yeah, it is slow.
>
> I compared the raw-block implementation from xen-qemu 4.1.0 and current
> upstream, in case xen-qemu has some missing bugfixes and found the following
> patch that looks a bit interesting
>
> commit 4899d10d142e97eea8f64141a3507b2ee1a64f52
> Author: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> Date: Mon Apr 19 13:34:11 2010 +0100
> raw-posix: Use pread/pwrite instead of lseek+read/write
>
> This patch combines the lseek+read/write calls to use pread/pwrite
> instead. This will result in fewer system calls and is already used by
> AIO.
>
>
> From the first look the patch cannot be backported 1:1, so i havent tried it
> yet, because i doubt that it can make such a huge difference. Or would it be
> worth a try?
>
> Any other ideas how/what to investigate this issue further, in case the write-
> speed should be better also without AIO? I know that the qdisk implementation
> is expected to be slower, but i would expect at least lets say 5 MB/s.
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-06-03 23:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-03 23:49 bad write performance with qdisk with larger files in pv-domU Ronny Hegewald
2011-06-03 23:16 ` Konrad Rzeszutek Wilk [this message]
2011-06-04 1:49 ` Ronny Hegewald
2011-06-06 11:49 ` Stefano Stabellini
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=20110603231639.GA21830@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=ronny.hegewald@online.de \
--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.