在io_uring出现之前，在Linux里大家都用epoll或者select，通过IO多路复用来避免阻塞IO。但是，epoll和select并没有彻底解决问题：当文件可读时，读操作仍需要应用程序自己完成，这个操作很显然是阻塞的。如果数据量很大（如1MB），很明显这要阻塞一段时间。类比copy loop和DMA的关系，能不能让kernel帮我们把数据加载好，以便应用程序可以在这段时间做其他事情（而不是阻塞）呢？这是io_uring要解决的问题之一。

io_uring（旧称aioring）是来自Facebook的Jens Axboe提出的一组新的异步IO系统调用，为Linux提供类似Windows NT IOCP（I/O Completion Port）的异步IO机制。io_uring于Linux 5.1被合并到内核主线。

1. 问题背景

io_uring是Linux的一组新的异步IO系统调用，提出它的目的是解决已有的Kernel AIO的一些设计缺陷。这些缺陷不仅影响性能（它有时阻塞！），还使得它很难用。

在这封邮件中，可以看到Linus痛骂已有的Kernel AIO设计之差；但是由于Linus著名的“不破坏用户态”的承诺，内核仍需继续维护这个API

2. Linux已有的异步IO方法

(1) POSIX AIO

api文档：https://man7.org/linux/man-pages/man7/aio.7.html

优点： 兼容性最好

缺点： 性能差。为了跨平台，使用了用户态实现（glibc），底层是多线程模型，队列深度受限于线程数量

(2) Kernel AIO

从Linux 2.6开始提供。这是一个基于状态机的内核态异步IO实现，最初的设计意图是提供异步磁盘IO操作（Asynchronous disk IO）。

因为它的接口还没有稳定下来，所以libc不提供包装函数，需要直接使用系统调用，或者使用内核组织提供的外部库libaio。

优点： 内核态的基于状态机的实现，比POSIX AIO的性能、可伸缩性（scalability）更好

缺点：

• Linux专有，其他UNIX系统不一定支持（和POSIX AIO相比）
• 不够成熟（暂不能用此重新实现POSIX AIO）
• 有些情况下仍会阻塞：
  • 只有无缓冲文件IO（O_DIRECT）、网络IO才可能是异步的。其他情况如有缓冲的文件IO，仍会阻塞
  • kernel AIO只给出使操作异步的必要条件，而非充分条件：Kernel AIO不能保证所有操作均不阻塞，在一些情况下（如一些和文件系统、磁盘硬件、驱动相关的情况），操作仍可能阻塞。
• 仍有明显的欠优化设计
  • 一个IO操作需要至少2个系统调用（执行、读取结果），且传递参数、向调用方返回值时存在冗余的内存拷贝（Linux 4.18引入了新的轮询机制IOCB_CMD_POLL。类似io_uring，通过将一个环形缓冲区从内核映射到用户态，可以将这里的系统调用次数减少到1）

(3) epoll (EPOLLET) + non-blocking socket (O_NONBLOCK)

优点：

• 自Linux 2.5.44被引入内核，兼容性好
• 比其他两种方案（POSIX AIO、Kernel AIO）的性能更好

缺点：只支持网络套接字

为什么epoll不能作用于硬盘io（regular file）呢？之前用select和poll的时候也没有这条限制呀。

其实select和poll也是“不支持”对regular file进行监控的，只不过它们被设计为可以接受regular file的fd，并对任何event全部返回True。 epoll在设计的时候，考虑到既然对regular file的fd进行polling是没有意义的，干脆我就不接受这种类型的fd，所以如果你传入一个真实文件的fd给epoll，它会直接报错返回-1，并将errno设置为EPERM错误码。

3. io_uring 面向性能的设计

(1) 完全异步的接口: 接口不会阻塞。

(2) 零拷贝（zero copy）通信

io_uring的输入输出均在共享缓冲区中进行，避免传参和返回值引入的冗余内存复制操作

(3) 最小化的（minimal）系统调用用量

io_uring可以在一个系统调用中发起多个IO操作，可以有效减少系统调用次数。在轮询（poll）模式下，内核甚至可以主动读取新增的任务，而不需要用户执行系统调用来提交。

4. 已有项目对于io_uring的支持情况

• Nginx: 以前使用epoll，现在增加了io_uring支持
• RocksDB: WIP
• libuv: 新增了io_uring支持

上一篇 « 下一篇 »