高性能计算是继理论科学和实验科学之后科学探索的第三范式，被广泛应用在高能物理研究、核武器设计、航天航空飞行器设计、国民经济的预测和决策等领域，对国民经济发展和国防建设具有重要的价值。它作为世界高技术领域的战略制高点，已经成为科技进步的重要标志之一，同时也是一个国家科技综合实力的集中体现。

作为信创云计算专家，华云数据已经在政府金融、国防军工、教育医疗、能源电力、交通运输等十几个行业打造了行业标杆案例，客户总量超过30万。在高性能计算方面也部下重局。在华云数据的研发和客户需求调研中发现，随着客户在高性能计算中的求解问题规模的越来越大，对计算能力和存储IO的需求不断增长，并成为计算和存储技术发展最直接的动力。

io_uring是Linux Kernel在v5.1版本引入的一套新异步编程框架，同时支持Buffer IO和Direct IO。io_uring 在设计之初就充分考虑框架自身的高性能和通用性，不仅仅面向传统基于块设备的FS/Block IO领域，对网络异步编程也提供支持，以通用的系统调用提供比肩spdk/dpdk 的性能。

1、基于fd的阻塞式 I/O：read()/write()

作为大家最熟悉的读写方式，Linux 内核提供了基于文件描述符的系统调用，这些描述符指向的可能是存储文件（storage file），也可能是network sockets：

ssize_t read(int fd, void *buf, size_t count);

ssize_t write(int fd, const void *buf, size_t count);

二者称为阻塞式系统调用（blocking system calls），因为程序调用这些函数时会进入sleep状态，然后被调度出去（让出处理器），直到 I/O 操作完成：

• 如果数据在文件中，并且文件内容已经缓存在page cache中，调用会立即返回；

• 如果数据在另一台机器上，就需要通过网络（例如 TCP）获取，会阻塞一段时间；

• 如果数据在硬盘上，也会阻塞一段时间。

缺点：

随着存储设备越来越快，程序越来越复杂， 阻塞式（blocking）已经这种最简单的方式已经不适用了。

2、非阻塞式 I/O：select()/poll()/epoll()

阻塞式之后，出现了一些新的、非阻塞的系统调用，例如select()、poll()以及更新的epoll()。应用程序在调用这些函数读写时不会阻塞，而是立即返回，返回的是一个已经ready的文件描述符列表。

缺点：只支持network sockets和pipes——epoll()甚至连storage files都不支持。

3、线程池方式

对于storage I/O，经典的解决思路是thread pool：主线程将 I/O分发给worker线程，后者代替主线程进行阻塞式读写，主线程不会阻塞。

这种方式的问题是线程上下文切换开销可能非常大，通过性能压测会看到。

4、Direct I/O（数据库软件）：绕过 page cache

随后出现了更加灵活和强大的方式：数据库软件（database software）有时并不想使用操作系统的page cache，而是希望打开一个文件后，直接从设备读写这个文件（direct access to the device）。这种方式称为直接访问（direct access）或直接 I/O（direct I/O）。

需要指定O_DIRECT flag；

• 需要应用自己管理自己的缓存 —— 这正是数据库软件所希望的；

• 是zero-copy I/O，因为应用的缓冲数据直接发送到设备，或者直接从设备读取。

5、异步IO

随着存储设备越来越快，主线程和worker线性之间的上下文切换开销占比越来越高。现在市场上的一些设备。换个方式描述，更能让我们感受到这种开销：上下文每切换一次，我们就少一次dispatch I/O的机会。因此Linux 2.6 内核引入了异步I/O（asynchronous I/O）接口。 

Linux 原生AIO 处理流程：

• 当应用程序调用io_submit系统调用发起一个异步IO 操作后，会向内核的 IO 任务队列中添加一个IO 任务，并且返回成功。

• 内核会在后台处理 IO 任务队列中的IO 任务，然后把处理结果存储在 IO 任务中。

• 应用程序可以调用io_getevents系统调用来获取异步IO 的处理结果，如果 IO 操作还没完成，那么返回失败信息，否则会返回IO 处理结果。

从上面的流程可以看出，Linux 的异步 IO 操作主要由两个步骤组成：

• 调用 io_submit 函数发起一个异步 IO 操作。

• 调用 io_getevents 函数获取异步 IO 的结果。

AIO的缺陷

• 仅支持direct IO。在采用AIO的时候，只能使用O_DIRECT，不能借助文件系统缓存来缓存当前的IO请求，还存在size对齐（直接操作磁盘，所有写入内存块数量必须是文件系统块大小的倍数，而且要与内存页大小对齐。）等限制，直接影响了aio在很多场景的使用。

• 仍然可能被阻塞。语义不完备。即使应用层主观上，希望系统层采用异步IO，但是客观上，有时候还是可能会被阻塞。io_getevents(2)调用read_events读取AIO的完成events，read_events中的wait_event_interruptible_hrtimeout等待aio_read_events，如果条件不成立（events未完成）则调用__wait_event_hrtimeout进入睡眠（当然，支持用户态设置最大等待时间）。

• 拷贝开销大。每个IO提交需要拷贝64+8字节，每个IO完成需要拷贝32字节，总共104字节的拷贝。这个拷贝开销是否可以承受，和单次IO大小有关：如果需要发送的IO本身就很大，相较之下，这点消耗可以忽略，而在大量小IO的场景下，这样的拷贝影响比较大。

• API不友好。每一个IO至少需要两次系统调用才能完成（submit和wait-for-completion)，需要非常小心地使用完成事件以避免丢事件。

• 系统调用开销大。也正是因为上一条，io_submit/io_getevents造成了较大的系统调用开销，在存在spectre/meltdown（CPU熔断幽灵漏洞，CVE-2017-5754）的机器上，若如果要避免漏洞问题，系统调用性能则会大幅下降。在存储场景下，高频系统调用的性能影响较大。

软件工程中，在现有接口基础上改进，相比新开发一套接口，往往有着更多的优势，然而在过去的数年间，针对上述限制的很多改进努力都未尽如人意。终于，全新的异步IO引擎io_uring就在这样的环境下诞生了。

io_uring 来自资深内核开发者 Jens Axboe 的想法，他在 Linux I/O stack 领域颇有研究。从最早的patch aio: support for IO polling 可以看出，这项工作始于一个很简单的观察：随着设备越来越快，中断驱动（interrupt-driven）模式效率已经低于轮询模式（polling for completions）。

• io_uring 的基本逻辑与 linux-aio 是类似的：提供两个接口，一个将 I/O 请求提交到内核，一个从内核接收完成事件。

• 但随着开发深入，它逐渐变成了一个完全不同的接口：设计者开始从源头思考 如何支持完全异步的操作。

1、原理及核心数据结构：

每个 io_uring 实例都有两个环形队列（ring），在内核和应用程序之间共享：

• 提交队列：submission queue (SQ)

• 完成队列：completion queue (CQ)

这两个队列：

• 都是单生产者、单消费者，size 是 2 的幂次；

• 提供无锁接口（lock-less access interface），内部使用 内存屏障做同步（coordinated with memory barriers）。

使用方式：

• 请求

• 应用创建 SQ entries (SQE)，更新 SQ tail；

• 内核消费 SQE，更新 SQ head。

• 完成

• 内核为完成的一个或多个请求创建 CQ entries (CQE)，更新 CQ tail；

• 应用消费 CQE，更新 CQ head。

• 完成事件（completion events）可能以任意顺序到达，到总是与特定的 SQE 相关联的。

• 消费 CQE 过程无需切换到内核态。

2、 三种工作模式

io_uring 实例可工作在三种模式：

(1)中断驱动模式（interrupt driven）

默认模式。可通过 io_uring_enter() 提交 I/O 请求，然后直接检查 CQ 状态判断是否完成。

(2)轮询模式（polled）

Busy-waiting for an I/O completion，而不是通过异步 IRQ（Interrupt Request）接收通知。

这种模式需要文件系统（如果有）和块设备（block device）支持轮询功能。相比中断驱动方式，这种方式延迟更低，但可能会消耗更多 CPU 资源。

目前，只有指定了 O_DIRECT flag 打开的文件描述符，才能使用这种模式。当一个读 或写请求提交给轮询上下文（polled context）之后，应用（application）必须调用 io_uring_enter() 来轮询 CQ 队列，判断请求是否已经完成。

对一个io_uring 实例来说，不支持混合使用轮询和非轮询模式。

(3)内核轮询模式（kernel polled）

这种模式中，会创建一个内核线程（kernel thread）来执行SQ 的轮询工作。

使用这种模式的 io_uring 实例，应用无需切到到内核态就能触发（issue）I/O 操作。通过SQ来提交SQE，以及监控CQ的完成状态，应用无需任何系统调用，就能提交和收割 I/O（submit and reap I/Os）。

如果内核线程的空闲时间超过了用户的配置值，它会通知应用，然后进入idle状态。这种情况下，应用必须调用io_uring_enter()来唤醒内核线程。如果 I/O 一直很繁忙，内核线性是不会 sleep 的。

3、重要特性

• IORING_SETUP_SQPOLL：创建一个内核线程进行sqe的处理（IO 提交），几乎完全消除用户态内核态上下文切换，消除spectre/ meltdown 缓解场景下对系统调用的性能影响，此特性需要额外消耗一个cpu核。

• ORING_SETUP_IOPOLL：配合blk-mq多队列映射机制，内核IO 协议栈开始真正完整支持IOpolling。

• IORING_REGISTER_FILES/ IORING_REGISTER_FILES_UPDATE/ IORING_UNREGISTER_FILES：减少fget/ fput原子操作带来的开销

• IORING_REGISTER_BUFFERS/ IORING_UNREGISTER_BUFFERS：通过提 前向内核 注册 buffer 减少 get_user_pages / unpin_user_pages 开销，应用适配存在一定难度。

• IORING_FEAT_FAST_POLL：网络编程新利器，向 epoll 等传统基于事件驱动的网络编程模型发起挑战，为用户态提供真正的异步编程 API 。

• ASYNC BUFFERED READS：更好的支持异步 buffered reads ，但当前对于异步 buffered write 的支持还不够完。

2、io_uring和spdk的对比

非polling模式，io_uring相比libaio提升不是很明显；在polling模式下，io_uring能与spdk接近，甚至在queue depth较高时性能更好，完爆libaio。

在queue depth较低时有约7%的差距，但在queue depth较高时基本接近。

以上数据来自来自Jens Axboe的测试：https://lore.kernel.org/linux-block/20190116175003.17880-1-axboe@kernel.dk/

结论：

io_uring在非polling模式下，相比libaio，性能提升不是非常显著。

io_uring在polling模式下，性能提升显著，与spdk接近，在队列深度较高时性能更好。

io_uring在kvm-qemu下的性能表现

1、直接启用io_uring的场景

下面测试结果在一台华云超融合一体机测试，qemu 5.0 已经支持了Asynchronous I/O的io_uring，只需要将虚拟机将驱动改成io_uring。

原理如下：

• guestOS的kernel和qemu通信通过 virtqueue

• io_uring通过SQ和CQ进行IO的管理

宿主机环境信息：

虚拟机环境信息

[global]
ioengine=libaio
time_based
direct=1
thread
group_reporting
randrepeat=0
norandommap
numjobs=4
ramp_time=10
runtime=600
filename=/dev/sdb

[randwrite-4k-io32]
bs=4k
iodepth=32
rw=randwrite
stonewall

[randread-4k-io32]
bs=4k
iodepth=32
rw=randread
stonewall

测试数据如下：

测试视频：

libaio的4k随机读写

io_uring的4k随机读写

总结：

1）、libaio和io_uring性能比较，io_uring性能提高不明显，没有跨越式的提升。

2）、目前io_uring 的virtio block开发还在持续进行，poll模式等高级功能没有release。很值得期待。具体参见：https://wiki.qemu.org/Features/IOUring

2、io passthrough场景

原理：

直接透传QEMU Block层

• io_uring的SQ和CQ都在GuestOS的kernel中

• qemu的virtio-blk修改了“fast path”

• 启用了polling模式

测试环境版本信息：

创建虚拟机

aio=io_uring -device virtio-blk-pci,drive=hd1,bootindex=2,io-uring-pt=on

测试结果：

测试数据来自：

https://static.sched.com/hosted_files/kvmforum2020/9c/KVMForum_2020_io_uring_passthrough_Stefano_Garzarella.pdf

总结：

1）、virtio-blk的性能只有裸设备性能的一半左右。

2）、io_uring passthrough的性能和裸设备持平。

3）、缺点需要在guestOS的kernel中打patch。

1、内核支持情况

2、io_uring 社区开发现状

当前 io_uring 社区开发主要聚焦在以下几个方面。

• io_uring 框架自身的迭代优化
  前面提到，io_uring 作为一种新型高性能异步编程框架，当前仍处于快速发展中。因此随着特性越来越丰富，以及各种稳定性问题的修复等等，代码也变得越来越臃肿。因此 io_uring 框架也需要同步”进化“，不断进行代码重构优化。
  通常异步编程一般是将工作交由线程池来做，但对于 io_uring 来说，这只是最坏的 slow path，例如异步读优化，就是想尝试尽量在当前上下文中处理。另外，在 sqpoll 模式下，io_uring 接管用户提交的系统调用，一个系统调用的执行与特定的进程上下文相关，因此 io_uring 需要维护系统调用进程的内存上下文，文件系统上下文等大量信息。同时 io_uring 作为一种框架，框架本身的开销应该尽可能的小，才能与用户态高性能框架 SPDK 对标，因此需要持续优化。

• 特性增强

• io_uring buffer registration 特性增强
  io_uring 的 buffer registration 特性可以用来减少读写操作时频繁的 get_user_pages()/unpin_user_pages() 调用，get_user_pages() 主要用来实现用户态虚拟地址到内核页的转换，会消耗一定的 cpu 资源。来自 Oracle 的同学这组patchset 让 buffer registration 特性支持更新和共享操作，更加方便用户态编程，目前已发到第三版。我们遇到一些业务也明确提出过需要 buffer registration 支持更新操作。

• fs/userfaultfd: support iouring and polling

• 来自 VMware 的同学这组 patchset 使得 userfaultfd 支持 io_uring，且支持 polling 模式。在RDMA，持久内存等高速场景，系统调用用户态内核态上下文切换的开销在 userfualtfd 整体开销的占比会非常突出，支持 io_uring 后，可以显著减少用户态内核态上下文切换，带来明显的性能提升。

• add io_uring with IOPOLL support in scsi layer

• io_uring 出现后，Linux 内核才真正完整地支持 iopoll，iopoll 相比于中断模式能带来明显的性能提升。此前只有nvme driver 对 iopoll 提供比较好的支持，现在 scsi 层也开始准备支持 iopoll。

• no-copy bvec

• 在用 io_uring 进行 IO 栈性能分析时，来自 Facebook 的 Pavel Begunkov 发现在 direct IO 场景下是不需要拷贝bvec 结构的，他提交的这组 patchset 可以进一步提高内核 direct IO 的性能。

• io_uring and Optane2

• block 社区已经开始重视提高 IO 栈性能，一种思路是利用高性能设备，借助 io_uring 压测 IO 栈，从而发现软件性能瓶颈。比如 Intel提供最新的 Gen2 Optane SSD 给 block / io_uring 的维护者 Jens Axboe 来做内核 IO 栈性能分析。

• fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK

• Jens Axboe 优化 vfs 的文件查询逻辑，从而可以使 io_uring 的 IORING_OP_OPENAT 操作效率更高。

• IO 栈协同优化
  借助 io_uirng 这一高性能异步编程框架，能比较容易地发现其他内核子系统的软件性能瓶颈，从而对其进行优化，以提高内核 IO 栈的整体性能。我们之前也基于这个思路发现了 block 层的几处优化，同时提出了 device mapper polling 打通的 RFC。

1、华云数据产品技术中心始终贴近用户，解决用户的实际问题，同时时刻关注业界的先进技术。得益于io_uring的优异的表现，华云数据在此方面投入大量资源。同时我们在RDMA、SPDK、vdpa、DPU、io_uring、eBPF等热门技术也有相关的研究及产品化的丰富经验，同时对社区不断的共享。

2、io_uring 是完全为性能而生的新一代 native async IO 模型，比 libaio 高级不少。通过全新的设计，共享内存，IO 过程不需要系统调用，由内核完成 IO的提交， 以及Polled IO机制，实现了高IOPS。相比kernel bypass，这种原生内核的方式显得友好一些。一定程度上，io_uring代表了Linux kernel block层的未来，至少从中我们可以看出一些block层进化的方向，而且我们看到io_uring也在快速发展，相信未来io_uring会更加的高效、易用，并拥有更加丰富的功能和更强的扩展能力。这让我们充满期待，NVMe的存储时代需要一个属于自己的高速IO引擎。

3、在kvm方面，qemu支持io_uring，在操作和运维方便比spdk的vhost简单很多。虽然支持的还不是很完善，但社区仍然在积极推进。希望这个早日release。

4、国内阿里在io_uring走的比较靠前，阿里有个专门的内核组在做相关的开发。OpenAnolis已经将io_uring纳入，并且在io_uring方面做了很多探索。通过社区的一些文章可以看到，阿里在数据库、web、echo_sever等相关的领域都已经应用了io_uring。