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
0xF2C6EA10.asc
Description: application/pgp-keys
