qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ein
Subject: Re: [Qemu-devel] Very poor IO performance which looks like some design problem.
Date: Mon, 13 Apr 2015 14:28:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]