Re: [Qemu-devel] Very poor IO performance which looks like some design problem.

[ein <ein.net@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1503 bytes --]

Dear Fam,

Check out my update please:
http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg01318.html

Using aio=native,cache=none results in 500%-2000% performance drop
comparing to bare metal and 300%-1000% comparing to
aio=threads,cache=unsafe.

I'd like to know what numbers should I expect. Can somebody share what
results do you have with aio=native in sequential IO ops? And of course
please add some info about disk and controller configuration.
Maybe there's some bug in current version of Qemu in Debian 8 - testing.
Package details: https://packages.debian.org/jessie/qemu-kvm . Version:
*qemu-kvm (1:2.1+dfsg-11) *

On 04/13/2015 03:45 AM, Fam Zheng wrote:
> On Fri, 04/10 22:38, ein wrote:
>> Qemu creates more than 70 threads and everyone of them tries to write to
>> disk, which results in:
>> 1. High I/O time.
>> 2. Large latency.
>> 2. Poor sequential read/write speeds.
>>
>> When I limited number of cores, I guess I limited number of threads as
>> well. That's why I got better numbers.
>>
>> I've tried to combine AIO native and thread setting with deadline
>> scheduler. Native AIO was much more worse.
>>
>> The final question, is there any way to prevent Qemu for making so large
>> number of processes when VM does only one sequential R/W operation?
> aio=native will make QEMU only submit IO from the IO thread, so you shouldn't
> see 70 threads with that. And that should usually be a better option for
> performance.
>
>
> Fam


[-- Attachment #1.2: Type: text/html, Size: 2204 bytes --]

[-- Attachment #2: 0xF2C6EA10.asc --]
[-- Type: application/pgp-keys, Size: 4055 bytes --]