On 6 Oct 2002, Greg Copeland wrote:
> On Sat, 2002-10-05 at 14:46, Curtis Faith wrote:
> >
> > 2) aio_write vs. normal write.
> >
> > Since as you and others have pointed out aio_write and write are both
> > asynchronous, the issue becomes one of whether or not the copies to the
> > file system buffers happen synchronously or not.
>
> Actually, I believe that write will be *mostly* asynchronous while
> aio_write will always be asynchronous. In a buffer poor environment, I
> believe write will degrade into a synchronous operation. In an ideal
> situation, I think they will prove to be on par with one another with a
> slight bias toward aio_write. In less than ideal situations where
> buffer space is at a premium, I think aio_write will get the leg up.
Browsed web and came across this piece of text regarding a Linux-KAIO
patch by Silicon Graphics...
"The asynchronous I/O (AIO) facility implements interfaces defined by the
POSIX standard, although it has not been through formal compliance
certification. This version of AIO is implemented with support from kernel
modifications, and hence will be called KAIO to distinguish it from AIO
facilities available from newer versions of glibc/librt. Because of the
kernel support, KAIO is able to perform split-phase I/O to maximize
concurrency of I/O at the device. With split-phase I/O, the initiating
request (such as an aio_read) truly queues the I/O at the device as the
first phase of the I/O request; a second phase of the I/O request,
performed as part of the I/O completion, propagates results of the
request. The results may include the contents of the I/O buffer on a
read, the number of bytes read or written, and any error status.
Preliminary experience with KAIO have shown over 35% improvement in
database performance tests. Unit tests (which only perform I/O) using KAIO
and Raw I/O have been successful in achieving 93% saturation with 12 disks
hung off 2 X 40 MB/s Ultra-Wide SCSI channels. We believe that these
encouraging results are a direct result of implementing a significant
part of KAIO in the kernel using split-phase I/O while avoiding or
minimizing the use of any globally contented locks."
Well...
> In a worse case scenario, it seems that aio_write does get a win.
>
> I personally would at least like to see an aio implementation and would
> be willing to even help benchmark it to benchmark/validate any returns
> in performance. Surely if testing reflected a performance boost it
> would be considered for baseline inclusion?