From mboxrd@z Thu Jan 1 00:00:00 1970 From: john cooper Subject: Re: virtio disk slower than IDE? Date: Mon, 16 Nov 2009 11:40:58 -0500 Message-ID: <4B01809A.9020605@third-harmonic.com> References: <4AFEBD59.2090002@bobich.net> <4AFFCF18.1080509@redhat.com> <4AFFED49.9010305@bobich.net> <4AFFFF0D.3090608@redhat.com> <4B00851F.5060206@bobich.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john cooper To: Gordan Bobic , KVM list Return-path: Received: from dpc6682208002.direcpc.com ([66.82.208.2]:42956 "EHLO anvil.third-harmonic.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753993AbZKPRT1 (ORCPT ); Mon, 16 Nov 2009 12:19:27 -0500 In-Reply-To: <4B00851F.5060206@bobich.net> Sender: kvm-owner@vger.kernel.org List-ID: Gordan Bobic wrote: > The test is building the Linux kernel (only taking the second run to > give the test the benefit of local cache): > > make clean; make -j8 all; make clean; sync; time make -j8 all > > This takes about 10 minutes with IDE disk emulation and about 13 minutes > with virtio. I ran the tests multiple time with most non-essential > services on the host switched off (including cron/atd), and the guest in > single-user mode to reduce the "noise" in the test to the minimum, and > the results are pretty consistent, with virtio being about 30% behind. I'd expect for an observed 30% wall clock time difference of an operation as complex as a kernel build the base i/o throughput disparity is substantially greater. Did you try a more simple/regular load, eg: a streaming dd read of various block sizes from guest raw disk devices? This is also considerably easier to debug vs. the complex i/o load generated by a build. One way to chop up the problem space is using blktrace on the host to observe both the i/o patterns coming out of qemu and the host's response to them in terms of turn around time. I expect you'll see somewhat different nature requests generated by qemu w/r/t blocking and number of threads serving virtio_blk requests relative to ide but the host response should be essentially the same in terms of data returned per unit time. If the host looks to be turning around i/o request with similar latency in both cases, the problem would be lower frequency of requests generated by qemu in the case of virtio_blk. Here it would be useful to know the host load generated by the guest for both cases. -john -- john.cooper@third-harmonic.com