AIO: Why is this so hard?
AIO lets tasks perform slow IO in the background while they do other
productive work with the CPU in the mean time. The Linux kernel has
limited support for performing AIO for a task but it has serious
limitations. This talk will cover the various problems that people have
had with AIO and how we might solve them. We'll introduce a subsystem
we're calling "acall" which hopes to move the state of Linux AIO
Users of the existing kernel AIO interface complain that it can block
the submitting task for significant amounts of time. Some people can't
use the existing kernel AIO interface because their operations aren't
supported. Few operations are supported by the existing kernel AIO
interface because it places a high maintenance burden on kernel code
which supports it. glibc doesn't use the existing kernel AIO interface
because it is a poor fit for implementing the POSIX AIO interface.
We'll shed light on these issues.
acall attempts to address these problems. The complexity lies in
acknowledging that people assume very different behavioural requirements
when they talk about AIO. We'll make these use cases explicit and
illustrate the knobs that acall has to satisfy different users.
Zach works on the kernel for the Linux Engineering group at Oracle from his home in Portland, Oregon, in the US. While at Oracle he has helped with the merge of OCFS2 into mainline and the maintenance of the AIO subsystem. He currently spends his time on on the design and implementation of BTRFS and CRFS. Before coming to Oracle he worked on the Lustre clustered file system.