Re: virtio disk slower than IDE?

[Gordan Bobic <gordan@bobich.net>]

john cooper 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.

I'm not convinced it's the read performance, since it's the second pass 
that is time, by which time all the source files will be in the guest's 
cache. I verified this by doing just one pass and priming it with:

find . -type f -exec cat '{}' > /dev/null \;

The execution times are indistinguishable from the second pass in the 
two-pass test.

To me that would indicate the the problem is with write performance, 
rather than read performance.

> 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.

With virtio the CPU usage did seem to be noticeably lower. I figured 
that was because it was spending more time waiting for I/O to finish, 
since it was clearly bottlenecking on disk I/O (since that's the only 
thing that changed).

I'll try iozone's write tests and see how that compares. If I'm right 
about write performance being problematic, iozone might show the same 
performance deterioration on write tests compared to the IDE emulation.

Gordan