qemu-devel
[Top][All Lists]
Advanced

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

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to a


From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Date: Sun, 20 Apr 2008 21:43:40 +0300
User-agent: Thunderbird 2.0.0.12 (X11/20080226)

Jamie Lokier wrote:
Avi Kivity wrote:
For the majority of deployments posix aio should be sufficient. The few that need something else can use Linux aio.

Does that mean "for the majority of deployments, the slow version is
sufficient.  The few that care about performance can use Linux AIO?"


In essence, yes. s/slow/slower/ and s/performance/ultimate block device performance/.

Many deployments don't care at all about block device performance; they care mostly about networking performance.

I'm under the impression that the entire and only point of Linux AIO
is that it's faster than POSIX AIO on Linux.

It is. I estimate posix aio adds a few microseconds above linux aio per I/O request, when using O_DIRECT. Assuming 10 microseconds, you will need 10,000 I/O requests per second per vcpu to have a 10% performance difference. That's definitely rare.

Of course, a managed environment can use Linux aio unconditionally if knows the kernel has all the needed goodies.

Does that mean "a managed environment can have some code which check
the host kernel version + filesystem type holding the VM image, to
conditionally enable Linux AIO?"  (Since if you care about
performance, which is the sole reason for using Linux AIO, you
wouldn't want to enable Linux AIO on any host in your cluster where it
will trash performance.)

Either that, or mandate that all hosts use a filesystem and kernel which provide the necessary performance. Take ovirt for example, which provides the entire hypervisor environment, and so can guarantee this.

Also, I'd presume that those that need 10K IOPS and above will not place their high throughput images on a filesystem; rather on a separate SAN LUN.

Just wondering.

Hope this clarifies.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

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