72
POWER7 and Optimization and Tuning Guide
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
Summary of Contents for Power System POWER7 Series
Page 2: ......
Page 36: ...20 POWER7 and POWER7 Optimization and Tuning Guide...
Page 70: ...54 POWER7 and POWER7 Optimization and Tuning Guide...
Page 112: ...96 POWER7 and POWER7 Optimization and Tuning Guide...
Page 140: ...124 POWER7 and POWER7 Optimization and Tuning Guide...
Page 162: ...146 POWER7 and POWER7 Optimization and Tuning Guide...
Page 170: ...154 POWER7 and POWER7 Optimization and Tuning Guide...
Page 223: ......
