Currently native linux AIO is properly supported (in the sense ofactually being asynchronous) only for files opened with O_DIRECT.While this suffices for a major (and most visible) user of AIO, i.e. databases,other types of users like Samba require AIO support for regular file IO.Also, for glibc POSIX AIO to be able to switch to using native AIO insteadof the current simulation using threads, it needs/expects asynchronousbehaviour for both O_DIRECT and buffered file AIO.

This patchset implements changes to make filesystem AIO readand write asynchronous for the non O_DIRECT case. This is mainlyrelevant in the case of reads of uncached or partially cached files, andO_SYNC writes.

Instead of translating regular IO to [AIO + wait], it translates AIOto [regular IO - blocking + retries]. The intent of implementing itthis way is to avoid modifying or slowing down normal usage, by keepingit pretty much the way it is without AIO, while avoiding code duplication.Instead we make AIO vs regular IO checks inside io_schedule(), i.e. atthe blocking points. The low-level unit of distinction is a wait queueentry, which in the AIO case is contained in an iocb and in thesynchronous IO case is associated with the calling task.

The core idea is that is we complete as much IO as we can in a non-blockingfashion, and then continue the remaining part of the transfer again whenwoken up asynchronously via a wait queue callback when pages are ready ... thus each iteration progresses through more of the request until it iscompleted. The interesting part here is that owing largely to the idempotencein the way radix-tree page cache traveral happens, every iteration is simplya smaller read/write. Almost all of the iocb manipulation and advancementin the AIO case happens in the high level AIO code, and rather than inregular VFS/filesystem paths.

The following is a sampling of comparative aio-stress results with thepatches (each run starts with uncached files):