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:53:26 -0500 Message-ID: <4B018386.7030804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: gordan@bobich.net, KVM list Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6112 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751827AbZKPRLa (ORCPT ); Mon, 16 Nov 2009 12:11:30 -0500 Sender: kvm-owner@vger.kernel.org List-ID: [prior attempts from elsewhere kept bouncing, apologies for any replication] 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@redhat.com