细说LinuxAIO之一

AIO的概述

AIO的概念？

AIO是异步IO的简写。实际上，AIO多指一套提供了异步IO的功能的函数。

所谓“异步”，是相对同步IO来讲的。那什么是同步iO？同步IO就是普通的LinuxIO函数，这里讲的三种常见的IO模式（https://zp001.blog.csdn.net/article/details/139305428）其实都是同步IO。
同步IO的意思是：读写函数比如read()、write()等，它返回的时候，它所代表的IO动作就已经完成。

而异步IO，则是说，读写函数返回的时候，它所代表的IO动作可能还没实际完成，你需要通过后续手段来获取完成情况。

AIO函数使用的三步骤

使用AIO函数比较啰嗦，但是捋清主要逻辑后，可发现大体上是三步骤：

准备IO。你要读还是写？写哪里？这些准备工作要先记录好。代表函数就是io_prep_pwrite()，io_prep_pread()等
提交IO。代表函数是io_submit()
收割IO。就是等待IO你提交的IO的完成。至于为什么叫收割，是因为它英文原文如此。代表函数是io_getevents()

libaio、内核源码和posix AIO

要使用AIO，要先安装libaio。安装命令也很简单yum -y install libaio-devel即可。安装之后，我们就可以在代码里面调用libaio的函数比如io_submit()

有人从这就误以为aio的功能主要是这个libaio库实现的。其实不是，它的源码也在github上，down下来会发现它只有500行。它仅仅是几个AIO系统调用的封装。

AIO系统调用的主要实现者是Linux内核，实现的主要逻辑在源码目录/fs/aio.c

这说明了libaio和内核系统调用是封装与被封装，使用者和实现者的关系。

比如libaio的函数io_submit()，它就封装了系统调用io_submit()。这两者的名称是一样的，在查看man page的时候要留意你看的是哪个函数的说明，别搞混了。

另外想想，如果是为了调用读写函数不阻塞，那么我新建一个线程调用它们就可以达到目的，没必要新开发专门的AIO系统调用函数呀。事实上，glibc就是这样在用户态实现了异步IO，这套函数被称为POSIX AIO，包含aio_read()、aio_write()等。

同样，别把libaio和POSIX AIO这两套函数搞混了，它们的原理大相径庭。

AIO的参考资料

介绍AIO的书籍比较少，较为重要的参考资料包括：

AIO系统调用的man page。比如在Linux上输入man io_submit，就能看到这个系统调用的说明，标题栏有“system call manual”字样。
libaio的源码。在github上可以获取。
libaio的man page。在源码目录中有man目录，把里面的文件复制到/usr/share/man/man3，然后man 3 io_submit就可以查看。这时候看到的man page标题有“Linux AIO"字样，和系统调用的io_submit函数区别开。
FIO源码中libaio ioengine源码。FIO是压测工具，看它怎么用AIO函数是非常有参考价值的，可以从它的选项中看到AIO有多少种使用方式，该怎么调用。总之，学习AIO、io_uring跟着axboe就对了。
AIO实现的内核源码。主要是io_setup()、io_submit()和io_getevent()三个系统调用的实现。
LWN上面有几篇说到AIO的文章，文章列表：https://lwn.net/Kernel/Index/#Asynchronous_IO
littledan的文章： https://github.com/littledan/linux-aio

示例代码

#define _GNU_SOURCE
#include <fcntl.h>
#include <libaio.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(void) {
  const char *content = "hello world\n";
  const char *outputfile = "/mnt/ext4/hello.txt";
  int fd;
  int ret;
  io_context_t ctx;
  struct iocb io, *pio = &io;
  struct io_event e;

  bzero(&ctx, sizeof(io_context_t));
  ret = io_setup(10, &ctx);
  if (ret != 0) {
    return 1;
  }
  if ((fd = open(outputfile, O_DIRECT | O_CREAT | O_TRUNC | O_WRONLY, 0644)) <
      0) {
    fprintf(stderr, "open() error, ret: %d\n", ret);
    goto err_out1;
  }

#define SECTORSIZE 512
  char _Alignas(SECTORSIZE) buf[SECTORSIZE];
  bzero(buf, SECTORSIZE);

  strcpy(buf, content);
  io_prep_pwrite(&io, fd, (void *)buf, SECTORSIZE, 0);

  ret = io_submit(ctx, 1, &pio);
  if (ret != 1) {
    fprintf(stderr, "io_submit() error, ret: %d\n", ret);
    goto err_out2;
    return 1;
  }

  ret = io_getevents(ctx, 1, 1, &e, NULL);
  if (ret != 1) {
    fprintf(stderr, "io_getevents() error, ret: %d\n", ret);
    goto err_out2;
  }
  close(fd);

  io_destroy(ctx);
  return 0;

err_out2:
  close(fd);
err_out1:
  io_destroy(ctx);
  return 1;
}

编译命令

gcc -std=gnu11 -Wall -laio aio.c

这个例子往文件里面写了个"hello world"

下面细细说来

异步使用IO函数

从上面例子，大概有种印象：所谓异步IO，就是异步使用IO函数：pread()、pwrite()这些。

       ssize_t pread(int fd, void buf[.count], size_t count,
                     off_t offset);
       ssize_t pwrite(int fd, const void buf[.count], size_t count,
                     off_t offset);

pread()、pwrite()本来是同步IO函数，open()之后就可以直接使用它们，但它们的默认行为是等IO完成后才返回。但经过AIO的prepare、并提交之后，就实现了异步形态的pread()和pwrite()。

这是对AIO最简单粗暴的理解。

类似的，AIO还可以prepare的函数包括：preadv()、pwritev()等

AIO和direct IO

这个AIO例子中使用了direct IO，所以directIO的四个要求全都要符合：

定义_GNU_SOURCE
open的时候打上O_DIRECT标记
buf要512字节对齐
buf长度要是512字节的倍数

更详细的directIO说明请见https://zp001.blog.csdn.net/article/details/139305428

网上不少文章都说AIO一定要使用directIO，其实不一定，内核很早就支持让AIO使用bufferedIO了，只不过使用bufferedIO不一定是个好选择，这里从惯例使用directIO。后续文章继续分说。

io_setup()

long io_setup(unsigned int nr_events, aio_context_t *ctx_idp);

io_setup()的作用就是生成这个aio_context_t结构对象ctx，后续一系列的操作都会用这个ctx来做标记凭证，表示这一系列操作与此ctx相关。

io_setup()有两个参数，两个参数都不太好理解。这两个参数的关系是这样的：

第二个参数 是AIO的context上下文（简称ctx），它代表一个环形队列，简单粗暴可以理解成队列，每个队列元素对应一个读写IO操作的完成状态，这个队列能暂存多少个IO，就是 第一个参数 nr_event所指定。

这个nr_event是什么东西呢？

第一个理解就是上述环形队列中暂存inflight（发出去但未完成） IO的个数。这个数量在整个OS范围内是有个限制的，使用sysctl -a可以看到当前系统的已经使用的数量以及最大数量。

❯ sysctl -a |grep aio
fs.aio-max-nr = 1048576 # 最大值
fs.aio-nr = 0 # 当前已使用的数量

当你io_setup(16,xxx)，上面fs.aio-nr就会增加16

但了解到这里并不足以让我们判断这里该输入8还是8192。

它的本质还是那个：inflight IO的个数的。所以该填什么，取决于你IO的目标能承受多少个并发的IO。

比如，你对/dev/sdb裸设备进行AIO，那么可以参考它的queue_depth值来设置，我的虚拟机中，这个值是32.

❯ cat /sys/block/sdb/device/queue_depth
32

如果你对普通文件进行AIO，那么也可以参考FS地下的设备的queue_depth来进行折算和调整，以性能测试为准。

但明确一点，这里设置的是inflight IO的最大值。即如果你设置了16，那么在下面一次调用io_submit()之前，你调用io_prep_xxx()的次数就不能超过16；调用io_submit()函数中的第二个参数的也不能超过16。

那是否需要一个ctx对应一个fd呢？其实并无限制。可以使用一个ctx对多个文件df进行IO。但如果一个ctx只对应一个fd，只少有一个好处，就是方便计算这个fd的inflight IO数量，方便编程让它时刻保持这个数量，达到压力最大，性能最大。

io_prep_pwrite()

inline void io_prep_pwrite(struct iocb *iocb, int fd, void *buf, size_t count, long long offset)

io_prep_pwrite()的作用是准备一个写IO操作（pwrite()），预先准备好这个pwrite()函数的所有参数，把这些参数存至iocb对象中去。此刻，并未调用pwrite()，也就是说，并没有开始进行IO

io_prep_pwrite()其实并不是要调用哪个系统调用，它仅仅是一个helper函数，方便我们程序员填充struct iocb而已。比如这个io_prep_pwriter()的源码也就下面这样，一目了然

static inline void io_prep_pwrite(struct iocb *iocb, int fd, void *buf, size_t count, long long offset)
{
	memset(iocb, 0, sizeof(*iocb));
	iocb->aio_fildes = fd;
	iocb->aio_lio_opcode = IO_CMD_PWRITE;
	iocb->aio_reqprio = 0;
	iocb->u.c.buf = buf;
	iocb->u.c.nbytes = count;
	iocb->u.c.offset = offset;
}

调用io_prep_pwrite()一次，就准备了一个iocb，io_submit()之后，inflight IO就增加了1。

从上面源码来看，经过prepared之后，一个IO操作所需的所有信息就存在了struct iocb里面，所以AIO使用iocb来代表一个IO操作。

io_submit()

int io_submit(io_context_t ctx, long nr, struct iocb *iocbs[]);

这个函数的作用是把之前准备好的io操作（也就是iocb对象）提交进内核。
我们在这个例子中只准备了一个pwrite()，当这个io_submit()调用完成后，pwrite()这个动作便会真正开始。

第一个参数不用说，就是之前io_setup()好的ctx。

第二个参数和第三个参数的作用就是把我们之前io_prep_xxx()准备好的iocb都告诉内核。它采用数组地址+数组数量的方式传参，是为了一次io_submit()能传递多个iocb对象。所以在调用io_submit()之前，我们要把所有的iocb对象的地址都存到一个数组中去。

io_submit() 的阻塞

这里要特意说的是，io_submit()这个函数应该很快就返回才对，它应该在提交的所有IO完成之前返回，从而实现“异步IO”的语义，对吧，如果它等所有IO都完成了才返回，那为啥还叫AIO呢？

这点在littledan的文章中写得很清楚：

When used under the right conditions, io_submit should not block. However, when used in certain ways, it may block, undermining the purpose of asynchronous I/O. — https://github.com/littledan/linux-aio

遗憾的是，现在还是有些情况会使得io_submit()卡住的，从而"退化"成了同步IO。

man page也提到，这些可能会使得io_submit()阻塞的情况包括：

文件系统层次中，为文件申请磁盘块
刷脏的page cache
锁竞争
文件系统下层的block设备IO拥塞（从这里看，并不是io_setup()中的nr_event越大越好）

如果你不想中这些情况中阻塞io_submit()，那么在4.14内核开始，可以使用RWF_NOWAIT标记来prepare该iocb，那么这时io_submit()就会马上返回-EAGAIN

         RWF_NOWAIT (since Linux 4.14)
                            Don't wait if the I/O will block for operations such as file block allocations, dirty page  flush,  mutex  locks, or a congested block device inside the kernel.  If any of these conditions are met, the control block is returned  immediately  with  a  return value of -EAGAIN in the res field of the io_event structure (see io_getevents(2)).

幸好，我们有strace工具，strace一下你的程序，就能知道它花在io_submit()中有多长时间，我们的“异步”是否有效。使用办法：

strace -c ./myaio

io_submit()的部分成功

io_submit()还有个特点，就是它允许部分成功。这是说，你提交8个IO，io_submit()返回的时候告诉你成功提交4个，该怎么办？

就是得让程序员看着办：再次提交没提交成功的那些IO。给程序员带来了编程的一点麻烦。

io_getevent()

int io_getevents(io_context_t ctx_id, long min_nr, long nr, struct io_event *events, struct timespec *timeout);

这个函数的作用就是在此阻塞，等待之前提交的IO的完成。

它要阻塞到什么时候呢？

至少有min_nr（参数二）个提交的IO完成
或者timeout（参数5）指定的时间到了

如果你看资料，会看到一个术语叫收割（reap），意思便是这个，等待IO完成。io_gentevents()是收割方式之一，它至少会收割min_nr个IO，最多收割nr个IO。

收割的IO的结果，存放于events数组里面。

这里用到了一个叫event的对象，为什么内核通知你IO完成是给你一个这个东西呢？

我们来看看一个正常的pwrite()的调用结果是什么。

ssize_t pwrite(int fd, const void buf[.count], size_t count, off_t offset);

可以看到，对于IO结果的描述，我们只需要一个ssize_t的返回值（下称ret）即可，其它的不需要。

但是AIO不能这么做，如果它直接给你返回一堆ret（ret数据组），你能分辨哪个ret是哪个IO操作的结果？所以内核还要告诉我们是哪个iocb的返回值，所以至少内核要返回两个东西：ret + iocb地址

但这也还不够方便，我必须拿这个返回的iocb地址和我之前保存的一堆iocb地址逐个比较才能知道是哪个IO操作产生的返回值，有无办法能在IO的过程中让我携带一些标记，好让我快速知道是我哪个IO操作返回来呢？有的，内核允许你夹带一个私货：iocb->data，你在prepared的时候保存一个什么东西到这个字段，IO完成后内核按照原样给你回传回来。

以上就是struct event的最主要的三个字段：ret返回值、iocb地址和一个你自定义的字段

struct io_event {
	PADDEDptr(void *data, __pad1); //用户自定义字段
	PADDEDptr(struct iocb *obj,  __pad2); // 对应的iocb对象地址
	PADDEDul(res,  __pad3); // io操作的返回值
	PADDEDul(res2, __pad4);
};

有个细节：pwrite()的返回值是个ssize_t，有符号数，因为它用<0的值表示io出错了；但是io_event->res是个无符号数，所以，要先把它转换成ssize_t才能知道是否IO出错。

为什么要使用AIO

现在回过头来想想，为什么要使用AIO。我想来想去，觉得有两个因素：它enable了异步的编程模式以及可以控制iodepth(性能加速)

异步编程模式

这要从同步IO开始说起，比如说一个程序调用了read()函数。这个函数的执行时间是多少呢？

根据《深入理解软件性能》P10，“每一位优秀的程序员都应该知道的数字”，大概可以获得一种印象：

磁盘访问的速度是毫秒级（ms）的

内存的速度是微秒（us）级的

CPU缓存的速度是纳秒（ns）级的

这是说，如果read()函数的调用时间为1ms，其实它有相当一部分时间是在等待IO的完成，如果我们能把这1ms拿出来跑代码，不进行IO操作，可以跑几千到几十万行代码，（只是为获得一个感性的印象而估计，别较真）。

异步编程作用就是这样，帮你把这1ms拿出来跑你的代码：你io_submit()之后，可以继续往下跑代码，不阻塞当前线程。

这当然是好事。

但另一方面，它也带来了编程的复杂性。即AIO给我们带来的两个API，io_submit()和io_getevent()，它们代表着新的一套编程思维。不信的话，可以想象一下，如何用AIO实现一个拷贝文件的程序，就会发现程序逻辑完全不同于普通的read()和write()。

其中的重点应该就是io_getevents()函数，不少人就喜欢围绕这个函数打造一个IO响应式框架，从而合理安排程序各部分逻辑。

一种顺理成章的思路就是：我用一个专用的线程，不停循环调用io_getevents()，每当有IO完成，我就用回调函数的办法通知程序的其它部分。

事实上，在libaio.h中就有这样的辅助函数，可以帮你完成上面的思路：

typedef void (*io_callback_t)(io_context_t ctx, struct iocb *iocb, long res, long res2);

static inline void io_set_callback(struct iocb *iocb, io_callback_t cb)
{
	iocb->data = (void *)cb;
}

它帮你预先定义好回调函数的格式，以及设置回调函数的方便函数io_set_callback()，然后利用iocb->data的字段来存放这个函数地址，那么在IO完成之后，也就是io_getevents()成功之后，就可以在event对象中取回这个函数地址，手工调用这个函数地址，从而完成一个简单的IO响应编程框架。

libaio也顺着这个思路帮我们对io_gentevents()做来简单封装，实现了io_queue_run()，如下，其实就是不断调用io_getevents()，然后等io返回后调用你设置的回调函数。

int io_queue_run(io_context_t ctx)
{
	static struct timespec timeout = { 0, 0 };
	struct io_event event;
	int ret;

	/* FIXME: batch requests? */
	while (1 == (ret = io_getevents(ctx, 0, 1, &event, &timeout))) {
		io_callback_t cb = (io_callback_t)event.data;
		struct iocb *iocb = event.obj;

		cb(ctx, iocb, event.res, event.res2);
	}

	return ret;
}

所以，可以使用上述函数实现简单的编程模型。

AIO带来的性能提升

不少人都会以为AIO要比普通IO更高级，性能更好。其实这样理解很模糊。

AIO真正能比普通IO要厉害的地方在于，它能让程序员控制inflight IO的个数，也就是说你能控制同时发几个IO。而普通的write() read()相当于同时只能发一个IO（要等函数返回，即上一个IO完成后，才能发下一个IO）。这一点可以从FIO的源码设计上得到辅证。

从上面的描述就知道，这事情并不绝对：

我可以用AIO同时发16个连续的、4KiB io size的IO，但我也可以用普通IO发一个64KiB io size的IO。很多时候，这两种做法的性能是一样的。
我用AIO同时发16个不连续的IO，另一方面，我用普通IO挨个发16个连续的IO，这两种情况就难以断定谁一定更快。

说回来，AIO的本质也就是能让程序员控制inflight IO的个数，如果它能带来性能提升，是因为它发出了受底层磁盘欢迎的IO pattern。

一般的磁盘喜欢连续的IO写入，并且有一定数量的并发IO接受能力（queue_depth），而使用AIO比较容易发出这样的IO，所以能获得性能提升。