Re: [Qemu-devel] Re: [PATCH 0/3] Refactor AIO to allow multiple AIO implementations

[Anthony Liguori <aliguori@us.ibm.com>]

Ryan Harper wrote:
> * Anthony Liguori <aliguori@us.ibm.com> [2008-09-22 22:44]:
>   
>> Can you run the same performance tests with the following patches (using 
>> sync=on instead of cache=off)?
>>
>> You'll need my aio_init fix too.  I suspect this will give equally good 
>> performance to your patch set.  That's not saying your patch set isn't 
>> useful, but I would like to get performance to be better for the case 
>> that we're going through the page cache.
>>     
>
> I can run the test, but it is orthogonal to the patchset which is
> focused on using O_DIRECT and linux-aio.
>   

Actually, I'm now much more interested in using the fd_pool patch with 
cache=off.  Using it with the sync=on patch is interesting but I'm 
curious how close fd_poll + cache=off gets to linux-aio + cache=off.

Supporting linux-aio is going to be a royal pain.  I don't know how we 
can do a runtime probe of whether we support resfd or not.  A build time 
probe is going to be lame because we'll be relying on the glibc 
headers.  Plus, I'm really, really interested in avoiding the 
association of cache=off == better performance.

In theory, the dup() + posix-aio should do okay compared to a custom 
thread pool.  It should have slightly higher latency, but completion 
time should be pretty close.  That would let us hold off supporting a 
thread pool until we're ready to do zero-copy IO (which is the only 
argument for a thread pool verses posix-aio).

Regards,

Anthony Liguori