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? ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly