From: Reeted <reeted@shiftmail.org>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
libvir-list@redhat.com, kvm@vger.kernel.org
Subject: Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on)
Date: Thu, 29 Sep 2011 01:27:06 +0200 [thread overview]
Message-ID: <4E83AD4A.8070107@shiftmail.org> (raw)
In-Reply-To: <4E833479.9060500@shiftmail.org>
On 09/28/11 16:51, Reeted wrote:
> On 09/28/11 14:56, Richard W.M. Jones wrote:
>> On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote:
>>> Ok that seems to work: it removes the vhost part in the virsh launch
>>> hence cutting down 12secs of boot time.
>>>
>>> If nobody comes out with an explanation of why, I will open another
>>> thread on the kvm list for this. I would probably need to test disk
>>> performance on vhost=on to see if it degrades or it's for another
>>> reason that boot time is increased.
>> Is it using CPU during this time, or is the qemu-kvm process idle?
>>
>> It wouldn't be the first time that a network option ROM sat around
>> waiting for an imaginary console user to press a key.
>>
>> Rich.
>
> Of the two qemu-kvm processes (threads?) which I see consuming CPU for
> that VM, one is at about 20%, the other at about 10%. I think it's
> doing something but maybe not much, or maybe it's really I/O bound and
> the I/O is slow (as I originarily thought). I will perform some disk
> benchmarks and follow up, but I can't do that right now...
> Thank you
Ok still didn't do benchmarks but I am now quite a lot convinced that
it's either a disk performance problem or cpu problem with vhostnet on.
Not a network performance problem or idle wait.
Because I have installed another virtual machine now, which is a fedora
core 6 (old!), but with a debian natty kernel vmlinuz + initrd so that
it supports virtio devices. The initrd part from Ubuntu is extremely
short so finishes immediately, but then the fedora core 6 boot is much
longer than with my previous ubuntu-barebone virtual machine, and with
more messages, and I can see the various daemons being brought up one by
one, and I can tell you such boot (and also the teardown of services
during shutdown) is very much faster with vhostnet disabled.
With vhostnet disabled it takes 30seconds to come up (since after grub),
and 28 seconds to shutdown.
With vhostnet enabled it takes 1m19sec to come up (since after grub),
and 1m04sec to shutdown.
I have some ideas about disk benchmarking, that would be fio or simple
dd. What could I use for CPU benchmarking? Would "openssl speed" be too
simple?
Thank you
next prev parent reply other threads:[~2011-09-28 23:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 18:10 Qemu/KVM is 3x slower under libvirt Reeted
2011-09-28 7:51 ` [libvirt] " Daniel P. Berrange
2011-09-28 9:19 ` Reeted
2011-09-28 9:28 ` Daniel P. Berrange
2011-09-28 9:49 ` Reeted
2011-09-28 9:53 ` [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on) Daniel P. Berrange
2011-09-28 10:19 ` Reeted
2011-09-28 10:29 ` Daniel P. Berrange
2011-09-28 12:56 ` Richard W.M. Jones
2011-09-28 14:51 ` Reeted
2011-09-28 23:27 ` Reeted [this message]
2011-09-29 0:39 ` [libvirt] Qemu/KVM is 3x slower under libvirt Chris Wright
2011-09-29 10:16 ` Reeted
2011-09-29 16:40 ` Chris Wright
2011-10-04 23:12 ` Qemu/KVM guest boots 2x slower with vhost_net Reeted
2011-10-09 21:47 ` Reeted
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=4E83AD4A.8070107@shiftmail.org \
--to=reeted@shiftmail.org \
--cc=berrange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=rjones@redhat.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 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).