Linux异步IO引擎：io-uring

梦里梦外; 2022-10-17 04:15 3566阅读 0赞

Phoronix 报道称，IO\_uring 可以说是 Linux 内核近期引入的最大创新之一，**因其能够显著提升移步输入/输出（async I/O）的效率**。一句话总结 io\_uring 就是：**一套全新的 syscall，一套全新的 async API，更高的性能，更好的兼容性，来迎接高 IOPS，高吞吐量的未来。**

先看一下性能数据（数据来自 Jens Axboe）。  
4k randread，3D Xpoint 盘：  
Interface QD Polled Latency IOPS  
………………………………………………………………  
io\_uring 1 0 9.5usec 77K  
io\_uring 2 0 8.2usec 183K  
io\_uring 4 0 8.4usec 383K  
io\_uring 8 0 13.3usec 449K

libaio 1 0 9.7usec 74K  
libaio 2 0 8.5usec 181K  
libaio 4 0 8.5usec 373K  
libaio 8 0 15.4usec 402K

io\_uring 1 1 6.1usec 139K  
io\_uring 2 1 6.1usec 272K  
io\_uring 4 1 6.3usec 519K  
io\_uring 8 1 11.5usec 592K

spdk 1 1 6.1usec 151K  
spdk 2 1 6.2usec 293K  
spdk 4 1 6.7usec 536K  
spdk 8 1 12.6usec 586K  
…………………………………………………………  
io\_uring vs libaio，在非 polling 模式下，io\_uring 性能提升不到 10%，好像并没有什么了不起的地方。然而 io\_uring 提供了 polling 模式。在 polling 模式下，io\_uring 和 SPDK 的性能非常接近，特别是高 QueueDepth 下，io\_uring 有赶超的架势，同时完爆 libaio。测试 per-core，4k randread 多设备下的最高 IOPS 能力：  
Interface QD Polled IOPS  
………………………………………………  
io\_uring 128 1 1620K  
libaio 128 0 608K  
spdk 128 1 1739K

最近几年一直流行 kernel bypass，从网络到存储，各个领域开花，内核在性能方面被各种诟病。io\_uring 出现以后，算是扳回一局。

io\_uring 有如此出众的性能，主要来源于以下几个方面：

用户态和内核态共享提交队列（submission queue）和完成队列（completion queue）  
IO 提交和收割可以 offload 给 Kernel，且提交和完成不需要经过系统调用（system call）  
支持 Block 层的 Polling 模式通过提前注册用户态内存地址，减少地址映射的开销  
通过提前注册用户态内存地址，减少地址映射的开销

不仅如此，io\_uring 还可以完美支持 buffered IO，而 libaio 对于 buffered IO 的支持则一直是被诟病的地方。

**io\_uring**

io\_uring 提供了一套新的系统调用，应用程序可以使用两个队列，Submission Queue（SQ) 和 Completion Queue（CQ) 来和 Kernel 进行通信。这种方式类似 RDMA 或者 NVMe 的方式，可以高效处理 IO。  
syscall  
425 io\_uring\_setup  
426 io\_uring\_enter  
427 io\_uring\_register

**io\_uring 准备阶段**

io\_uring\_setup 需要两个参数，entries 和 io\_uring\_params。  
其中 entries，代表 queue depth。  
io\_uring\_params 的定义如下。  
struct io\_uring\_params \{  
\_\_u32 sq\_entries;  
\_\_u32 cq\_entries;  
\_\_u32 flags;  
\_\_u32 sq\_thread\_cpu;  
\_\_u32 sq\_thread\_idle;  
\_\_u32 resv\[5\];  
struct io\_sqring\_offsets sq\_off;  
struct io\_cqring\_offsets cq\_off;  
\};

struct io\_sqring\_offsets \{  
\_\_u32 head;  
\_\_u32 tail;  
\_\_u32 ring\_mask;  
\_\_u32 ring\_entries;  
\_\_u32 flags;  
\_\_u32 dropped;  
\_\_u32 array;  
\_\_u32 resv1;  
\_\_u64 resv2;  
\};

struct io\_cqring\_offsets \{  
\_\_u32 head;  
\_\_u32 tail;  
\_\_u32 ring\_mask;  
\_\_u32 ring\_entries;  
\_\_u32 overflow;  
\_\_u32 cqes;  
\_\_u64 resv\[2\];  
\};  
其中，flags、sq\_thread\_cpu、sq\_thread\_idle 属于输入参数，用于定义 io\_uring 在内核中的行为。其他参数属于输出参数，由内核负责设置。

在 io\_setup 返回的时候，内核已经初始化好了 SQ 和 CQ，此外，还有内核还提供了一个 Submission Queue Entries（SQEs）数组。  
![11][]  
之所以额外采用了一个数组保存 SQEs，是为了方便通过 RingBuffer 提交内存上不连续的请求。SQ 和 CQ 中每个节点保存的都是 SQEs 数组的偏移量，而不是实际的请求，实际的请求只保存在 SQEs 数组中。这样在提交请求时，就可以批量提交一组 SQEs 上不连续的请求。

但由于 SQ，CQ，SQEs 是在内核中分配的，所以用户态程序并不能直接访问。io\_setup 的返回值是一个 fd，应用程序使用这个 fd 进行 mmap，和 kernel 共享一块内存。

这块内存共分为三个区域，分别是 SQ，CQ，SQEs。kernel 返回的 io\_sqring\_offset 和 io\_cqring\_offset 分别描述了 SQ 和 CQ 的指针在 mmap 中的 offset。而 SQEs 则直接对应了 mmap 中的 SQEs 区域。

mmap 的时候需要传入 MAP\_POPULATE 参数，以防止内存被 page fault。

**IO 提交**

IO 提交的做法是找到一个空闲的 SQE，根据请求设置 SQE，并将这个 SQE 的索引放到 SQ 中。SQ 是一个典型的 RingBuffer，有 head，tail 两个成员，如果 head == tail，意味着队列为空。SQE 设置完成后，需要修改 SQ 的 tail，以表示向 RingBuffer 中插入一个请求。

当所有请求都加入 SQ 后，就可以使用 ：

int io\_uring\_enter(unsigned int fd, u32 to\_submit, u32 min\_complete, u32 flags);

来提交 IO 请求。

io\_uring\_enter 被调用后会陷入到内核，内核将 SQ 中的请求提交给 Block 层。to\_submit 表示一次提交多少个 IO。

如果 flags 设置了 IORING\_ENTER\_GETEVENTS，并且 min\_complete > 0，那么这个系统调用会同时处理 IO 收割。这个系统调用会一直 block，直到 min\_complete 个 IO 已经完成。

这个流程貌似和 libaio 没有什么区别，IO 提交的过程中依然会产生系统调用。

**但 io\_uring 的精髓在于，提供了 submission offload 模式，使得提交过程完全不需要进行系统调用。**

如果在调用 io\_uring\_setup 时设置了 IORING\_SETUP\_SQPOLL 的 flag，内核会额外启动一个内核线程，我们称作 SQ 线程。这个内核线程可以运行在某个指定的 core 上（通过 sq\_thread\_cpu 配置）。这个内核线程会不停的 Poll SQ，除非在一段时间内没有 Poll 到任何请求（通过 sq\_thread\_idle 配置），才会被挂起。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70]  
当程序在用户态设置完 SQE，并通过修改 SQ 的 tail 完成一次插入时，如果此时 SQ 线程处于唤醒状态，那么可以立刻捕获到这次提交，这样就避免了用户程序调用 io\_uring\_enter 这个系统调用。如果 SQ 线程处于休眠状态，则需要通过调用 io\_uring\_enter，并使用 IORING\_SQ\_NEED\_WAKEUP 参数，来唤醒 SQ 线程。用户态可以通过 sqring 的 flags 变量获取 SQ 线程的状态。

**IO 收割**

当 IO 完成时，内核负责将完成 IO 在 SQEs 中的 index 放到 CQ 中。由于 IO 在提交的时候可以顺便返回完成的 IO，所以收割 IO 不需要额外系统调用。这是跟 libaio 比较大的不同，省去了一次系统调用。

如果使用了 IORING\_SETUP\_SQPOLL 参数，IO 收割也不需要系统调用的参与。由于内核和用户态共享内存，所以收割的时候，用户态遍历 \[cring->head, cring->tail) 区间，这是已经完成的 IO 队列，然后找到相应的 CQE 并进行处理，最后移动 head 指针到 tail，IO 收割就到此结束了。

由于提交和收割的时候需要访问共享内存的 head，tail 指针，所以需要使用 rmb/wmb 内存屏障操作确保时序。

所以在最理想的情况下，IO 提交和收割都不需要使用系统调用。

**其它高级特性**

io\_uring 支持还支持以下特性。

**IORING\_REGISTER\_FILES**

这个的用途是避免每次 IO 对文件做 fget/fput 操作，当批量 IO 的时候，这组原子操作可以避免掉。

**IORING\_SETUP\_IOPOLL**

这个功能让内核采用 Polling 的模式收割 Block 层的请求。当没有使用 SQ 线程时，io\_uring\_enter 函数会主动的 Poll，以检查提交给 Block 层的请求是否已经完成，而不是挂起，并等待 Block 层完成后再被唤醒。使用 SQ 线程时也是同理。

通过 perf 可以看到，当使用 IOPOLL 时，88% 的 CPU 时间花费在调用 blkdev\_iopoll 和 blk\_poll 上。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 1]  
**IORING\_REGISTER\_BUFFERS**

如果应用提交到内核的虚拟内存地址是固定的，那么可以提前完成虚拟地址到物理 pages 的映射，避免在 IO 路径上进行转换，从而优化性能。用法是，在 setup io\_uring 之后，调用 io\_uring\_register，传递 IORING\_REGISTER\_BUFFERS 作为 opcode，参数是一个指向 iovec 的数组，表示这些地址需要 map 到内核。在做 IO 的时候，使用带 FIXED 版本的opcode（IORING\_OP\_READ\_FIXED /IORING\_OP\_WRITE\_FIXED）来操作 IO 即可。

内核在处理 IORING\_REGISTER\_BUFFERS 时，提前使用 get\_user\_pages 来获得 userspace 虚拟地址对应的物理 pages。在做 IO 的时候，如果提交的虚拟地址曾经被注册过，那么就免去了虚拟地址到 pages 的转换。

下面是两个版本的 perf 数据。

带 fixed buffer：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 2]

不带 fixed buffer：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 3]  
可以明显看到，提前 map pages，可以减少 iov\_iter\_get\_pages 7% 的 CPU 时间消耗。

**关于名字**

取名一直是一个老大难的问题，io\_uring 这个名字，有点意思，社区有人吐槽，看起来像 io urine（*不是一个很好的词*），太欢乐了。

有人说可以叫做 aio\_ring，io\_ring，ring\_io。

**总结**

io\_uring 的接口虽然简单，但操作起来有些复杂，需要手动 mmap 来映射内存。可以看到，io\_uring 是完全为性能而生的新一代 native async IO 模型，比 libaio 高级不少。通过全新的设计，共享内存，IO 过程不需要系统调用，由内核完成 IO 的提交， 以及 IO completion polling 机制，实现了高IOPS，高 Bandwidth。相比 kernel bypass，这种 native 的方式显得友好一些。当然，不可否认，aio 也在与时俱进。自从 kernel 2.5 进入 upstream 以来，aio 一直都没有实现完整。 aio 对 Direct IO 支持的很好，但是其他的 IO 类型支持的不完善。尝试使用其他类型的 IO，例如 buffered IO，可能导致同步的行为。polling 也是一个方向，最近 aio 的 polling 机制已经实现，感兴趣的可以尝试一下。

作者：SmartX

[11]: /images/20221014/d1b6e954ae7145bb93020b4ac2ab3bb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70]: /images/20221014/7846ed16ac1b440d84ea75483ac6dea0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 1]: /images/20221014/3061124185f94ea58133f8660df1a0bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 2]: /images/20221014/39a55fc261254163ac75d70486b1a598.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RzMTEzMDA3MTcyNw_size_16_color_FFFFFF_t_70 3]: /images/20221014/ad4f7ddd567942e488f21591cb3552e4.png