IBM Power7 Optimization And Tuning Manual page 88

Concurrent I/O
An AIX JFS2 inode lock imposes write serialization at the file level. Serializing write accesses
prevents data inconsistency because of overlapping writes. Serializing reads regarding writes
ensures that the application does not read stale data.
However, some applications can choose to implement their own data serialization, usually at
a finer level of granularity than the file. Therefore, they do not need the file system to
implement this serialization for them. The inode lock hinders performance in such cases, by
unnecessarily serializing non-competing data accesses. For such applications, AIX offers the
concurrent I/O (CIO) option. Under concurrent I/O, multiple threads can simultaneously
perform reads and writes on a shared file. Applications that do not enforce serialization for
accesses to shared files should not use concurrent I/O, as it can result in data corruption
because of competing accesses.
Enhanced JFS supports concurrent file access to files. Similar to direct I/O, this access
method bypasses the file cache and transfers data directly from disk into the user
space buffer.
Concurrent I/O can be specified for a file either by running mount -o cio or by using the
open() system call (by using O_CIO as the OFlag parameter).
Asynchronous I/O
If an application does a synchronous I/O operation, it must wait for the I/O to complete. In
contrast, asynchronous I/O operations run in the background and do not block user
applications, which improves performance, because I/O operations and applications
processing can run simultaneously. Many applications, such as databases and file servers,
take advantage of the ability to overlap processing and I/O.
Applications can use the aio_read(), aio_write(), or lio_listio() subroutines (or their
64-bit counterparts) to perform asynchronous disk I/O. Control returns to the application from
the subroutine when the request is queued. The application can then continue processing
while the disk operation is being performed.
I/O completion ports
A limitation of the AIO interface that is used in a threaded environment is that aio_nwait()
collects completed I/O requests for all threads in the same process. One thread collects
completed I/O requests that are submitted by another thread.
Another limitation is that multiple threads cannot invoke the collection routines (such as
aio_nwait()) at the same time. If one thread issues aio_nwait() while another thread is
calling it, the second aio_nwait() returns EBUSY. This limitation can affect I/O performance
when many I/Os must run at the same time and a single thread cannot run fast enough to
collect all the completed I/Os.
On AIX, using I/O completion ports with AIO requests provides the capability for an
application to capture the results of various AIO operations on a per-thread basis in a
multi-threaded environment. This functionality provides threads with a method of receiving a
completion status for only the AIO requests initiated by the thread.
You can enable IOCP on AIX by running smitty iocp. Verify that IOCP is enabled by running
the following command:
lsdev -Cc iocp
The resulting output should match the following example:
iocp0 Available I/O Completion Ports
72
POWER7 and POWER7+ Optimization and Tuning Guide