Serialization of AIO requests to the same fd in posix-aio

Anthony Liguori aliguori@us.ibm.com
Wed Oct 8 20:21:00 GMT 2008


Hi Ulrich,

In sysdeps/pthread/aio_misc.c:__aio_enqueue_request(), there is a check 
to see if an existing thread is working on the same file descriptor as 
the request being enqueued.  If it is, it queues it to run after the 
existing request instead of possibly spawning a new thread.

The net effect is that submitting multiple requests to the same file 
descriptor are always serialized.  This significantly affects performance.

The comment beneath this check says:

      /* The current file descriptor is worked on.  It makes no sense
     to start another thread since this new thread would fight
     with the running thread for the resources.  But we also cannot
     say that the thread processing this desriptor shall immediately
     after finishing the current job process this request if there
     are other threads in the running queue which have a higher
     priority.  */

I don't understand what "fight with the running thread" is supposed to 
suggest.  Is this suggesting that there is some fundamental race 
condition?  Is it assuming that two IO requests cannot happen at the 
same time at the kernel level?  Since the threads end up using 
pread/pwrite, it should be safe to have two request executing 
simultaneously.

Currently, we use posix-aio for disk IO in QEMU/KVM.  To achieve good 
performance, we have to implement a fd pool using dup() to work around 
this check.  The difference between using the pool and not using the 
pool is around 400% in write performance.

Can you further elaborate on what this check is trying to prevent?

Thanks,

Anthony Liguori



More information about the Libc-help mailing list