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