From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reeted Subject: Re: [libvirt] Qemu/KVM is 3x slower under libvirt (due to vhost=on) Date: Wed, 28 Sep 2011 16:51:37 +0200 Message-ID: <4E833479.9060500@shiftmail.org> References: <4E82118D.2010702@shiftmail.org> <20110928075138.GC21102@redhat.com> <4E82E6AF.5070009@shiftmail.org> <20110928092859.GO21102@redhat.com> <4E82ED8D.10004@shiftmail.org> <20110928095339.GP21102@redhat.com> <4E82F49D.5000304@shiftmail.org> <20110928125614.GB5248@amd.home.annexia.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Daniel P. Berrange" , libvir-list@redhat.com, kvm@vger.kernel.org To: "Richard W.M. Jones" Return-path: Received: from blade3.isti.cnr.it ([194.119.192.19]:54047 "EHLO BLADE3.ISTI.CNR.IT" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751175Ab1I1OwU (ORCPT ); Wed, 28 Sep 2011 10:52:20 -0400 Received: from [192.168.7.52] (firewall.itb.cnr.it [155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5-x5 #31918) with ESMTPSA id <01O6LDT976DQXZNC0F@mx.isti.cnr.it> for kvm@vger.kernel.org; Wed, 28 Sep 2011 16:51:37 +0200 (MEST) In-reply-to: <20110928125614.GB5248@amd.home.annexia.org> Sender: kvm-owner@vger.kernel.org List-ID: 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