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

[Avi Kivity <avi@qumranet.com>]

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.