Linux Kernel To Get AIO Performance Improvements

[uid313]

The kernel's VFS layer provides AIO functions. However, writing programs that take advantage of asynchronous operations requires more effort than those using their traditional UNIX counterparts. Utilizing AIO provides no benefit unless your program is a daemon that can do other things while waiting for IO.

Well would be pretty cool on Web and FTP servers.

[babali]

Well you don't have asynchronous sendfile or splice. You don't have asynchronous stat/opendir/readdir/... as well. And the interface is not the same depending on the fd type. I don't think that AIO will work on something different from regular file.

Do you have any news about syslets?

[Haegar15]

IMHO asynchronous file I/O is still a mess on Linux.

As already stated in this thread the POSIX-AIO is implemented in user-space with a pool of blocking threads. The reason why it is not using the Kernel-AIO is the lack of features in AIO.

There are 3 reasons not to use the Kernel-AIO:
1. It only works with the O_DIRECT-flag, which means no buffering and very slow I/O.
2. Kernel-AIO needs support of the file-system in the kernel. Which file-systems are supported is a little bit of a mystery. Does CIFS or NFS support it?
3. When you finally use it it only runs on Linux, but not on BSD-systems.

I come from a windows background and I have to admit that the IO-Completion-Ports (IOCP) is a much superior API compared with what Linux has to offer. It works since Windows 2000, supports sockets and ALL kind of file-handles.
The Kernel-AIO moves the right direction, but the progress is very slow and hardly anybody is using it.

I wrote a high-performance-server on windows and wonder how I would have achieved the asynchronous file-I/O on Linux.

[curaga]

Why would you need AIO specifically - ie, why would it be better than say epoll + threads?

[Haegar15]

Why would you need AIO specifically - ie, why would it be better than say epoll + threads?

Because epoll, select and poll only works properly with sockets and not with files on Linux.

Having blocking threads doing the read/write operations does not scale.
An asynchronous reactor- or proactor-pattern is a much better approach.

[curaga]

It's also much more complex and so bug-prone.

Okay, so say you're doing a lot of writing of files to a slow HDD. What do you gain from AIO when compared to regular O_NONBLOCK?

[Haegar15]

It's also much more complex and so bug-prone.

It only feels complex if you are not used to. Programming with multiple threads is also more complex than single-threaded applications. But the benefit is worth the effort.
I have worked with big projects which used blocking I/O and with ones that used a completely asynchronous approach. In the end the asynchronous design was accepted by much more developers because they saw the benefit.

IMHO it is not hard to develop programs which use an asynchronous I/O approach. The main reason that a lot of people think it is more complex and bug-prone is because pretty much ALL examples of I/O (sockets or files) are blocking and it is hard to find good examples of the async way. That's why everbody starts with blocking I/O until they find out that it is not the best solution.

I can encourage everybody who is interested in the topic to look at the boost::asio library which is an excellent platform-independent API for asynchronous I/O. (but no async file I/O on linux)

Okay, so say you're doing a lot of writing of files to a slow HDD. What do you gain from AIO when compared to regular O_NONBLOCK?

Actually I didn't try out if the O_NONBLOCK-flag does work properly with files on Linux. But even when it returns EWOULDBLOCK when the operation would block, you still don't know when you can call it again and when the operation would complete without blocking (select or epoll won't work). You still have to work around the same problems as with blocking I/O.