From: "René Pfeiffer" <lynx@luchs.at>
To: kvm@vger.kernel.org
Subject: Re: I/O performance of VirtIO
Date: Mon, 12 Oct 2009 23:54:01 +0200 [thread overview]
Message-ID: <20091012215401.GE10688@nightfall.luchs.at> (raw)
In-Reply-To: <4AD3A38D.3090102@msgid.tls.msk.ru>
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
On Oct 13, 2009 at 0145 +0400, Michael Tokarev appeared and said:
> René Pfeiffer wrote:
> >Hello!
> >
> >I just tested qemu-kvm-0.11.0 with the KVM module of kernel 2.6.31.1. I
> >noticed that the I/O performance of an unattended stock Debian Lenny
> >install dropped somehow. The test machines ran with kvm-88 and 2.6.30.x
> >before. The difference is very noticeable (went from about 5 minutes up
> >to 15-25 minutes). The two test machines have different CPUs (one is an
> >Intel Core2 CPU, the other runs with an AMD Athlon 64 X2 Dual).
> >
> >Is this the effect of added code regarding caching/data integrity to the
> >VirtIO block layer or somewhere else? The qemu-system-x86_64 seems to
> >hang a lot more in heavy I/O (showing 'D' in top/htop).
> >
> >The command line is quite straight-forward:
> >qemu-system-x86_64 -drive file=debian.qcow2,if=virtio,boot=on -cdrom \
> >/srv/isos/debian-502-i386-netinst.iso -smp 2 -boot d -m 512 -net nic \
> >-net user -usb
> ^^^^^^^^^
>
> Care to try with something more real than user-level networking?
Yes, I tried that on the other machine. It made not much difference (the
installation files are on local Squid proxies).
But I found that setting cache=writeback restores the old behaviour. I
think the default changed to cache=writethrough.
> You're using netinstall which - apparently - tries to use some
> networking d/loading components etc, and userlevel networking is
> known to be very very slow....
Right, I just verified the disk I/O performance with severall runs of
hdparm and fresh installations using cache=none, cache=writeback and
cache=writethrough settings. The network settings were the same (the
test machine with the software bridge setup is down at the moment). I
wanted to compare the behaviour of the I/O load.
Best,
René.
--
)\._.,--....,'``. fL Let GNU/Linux work for you while you take a nap.
/, _.. \ _\ (`._ ,. R. Pfeiffer <lynx at luchs.at> + http://web.luchs.at/
`._.-(,_..'--(,_..'`-.;.' - System administration + Consulting + Teaching -
Got mail delivery problems? http://web.luchs.at/information/blockedmail.php
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2009-10-12 21:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 20:49 I/O performance of VirtIO René Pfeiffer
2009-10-12 21:45 ` Michael Tokarev
2009-10-12 21:54 ` René Pfeiffer [this message]
2009-10-13 6:35 ` Jan Kiszka
2009-10-22 16:29 ` Avi Kivity
2009-10-22 22:06 ` Alexander Graf
2009-10-25 5:44 ` Avi Kivity
2009-10-26 8:12 ` Jan Kiszka
2009-10-26 8:35 ` Avi Kivity
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=20091012215401.GE10688@nightfall.luchs.at \
--to=lynx@luchs.at \
--cc=kvm@vger.kernel.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).