io_uring 革命：Linux 异步 I/O 的深度架构解析与实战

2.2 提交 I/O 请求

// 获取空的 SQE
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
// 准备 pread 操作
io_uring_prep_read(sqe, fd, buf, nbytes, offset);
// 设置 user_data 用于后续匹配 CQE
io_uring_sqe_set_data(sqe, my_data);

// 提交所有准备好的 SQE（可能触发 io_uring_enter，也可能不触发）
io_uring_submit(&ring);

关键理解：io_uring_submit() 不是立即触发系统调用。仅在以下情况才执行 io_uring_enter：

1. 内核 SQ 线程（SQPOLL 模式下）尚未启动或需要唤醒
2. SQ 队列在过去未被内核看到过（需要刷写内存屏障）

2.3 收割完成事件

struct io_uring_cqe *cqe;
unsigned head;
int count = 0;

// 遍历 CQ 中的完成条目
io_uring_for_each_cqe(&ring, head, cqe) {
    // 处理完成：cqe->user_data 对应请求标识，cqe->res 是返回值
    handle_completion(cqe->user_data, cqe->res);
    count++;
}
// 已处理的 CQE 可以出队，释放回 SQ 重用
io_uring_cq_advance(&ring, count);

io_uring_for_each_cqe() 是一个宏，内部通过内存屏障同步 SQ 与 CQ 的 head 指针。这里的 cqe->res 对于 read 操作返回实际读取字节数（负值为 errno），对于 write 类似。

三、高级特性

3.1 链接请求 (IOSQE_IO_LINK)

io_uring 支持请求间的顺序链式执行：将前一个 SQE 设置 IOSQE_IO_LINK 标志，则后续 SQE 必须等前一个完成后才执行。这实现了原子的"预读 → 处理 → 写回"管道。

struct io_uring_sqe *sqe1 = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe1, fd, header_buf, 4096, 0);
io_uring_sqe_set_flags(sqe1, IOSQE_IO_LINK);  // 链接标记

struct io_uring_sqe *sqe2 = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe2, fd, body_buf, filesize, 4096);
// sqe2 等待 sqe1 完成后才执行

3.2 固定缓冲区与文件 (Registered Buffers & Files)

每次传统 I/O 系统调用都需要将用户缓冲区映射到内核空间（get_user_pages），请求完成后取消映射。对于高频小 I/O，这一开销不可忽视。

io_uring 允许提前注册缓冲区和文件描述符：

// 注册一组缓冲区
struct iovec iov = { .iov_base = buf, .iov_len = BUF_SIZE };
io_uring_register_buffers(&ring, &iov, 1);

// 注册一组文件
int fds[] = { fd1, fd2, fd3 };
io_uring_register_files(&ring, fds, 3);

// 使用时通过 IOSQE_BUFFER_SELECT / IORING_OP_READ_FIXED 指定索引

注册后的缓冲区只需映射一次，后续 I/O 操作直接复用内核页表映射。

3.3 轮询模式 (IORING_SETUP_IOPOLL) 与内核侧轮询 (SQPOLL)

对于 NVMe SSD 等延迟低于 10μs 的设备，中断开销成为瓶颈。io_uring 提供两种轮询模式：

• IOPOLL：内核侧使用 blk-mq polling 模式代替 IRQ，设备完成 I/O 后内核立即从 CQ 取结果，避免中断处理路径
• SQPOLL：内核创建一个高优先级 SQ 线程（io_wq）持续轮询 SQ，用户态提交请求时无需执行 io_uring_enter，完全零系统调用

四、liburing 缓冲区选择：IOSQE_BUFFER_SELECT

在网络 I/O 中，常见的"先读头部确定长度，再读正文"模式需要两次 read。liburing 支持提供缓冲区组（Buffer Group）模式，内核在处理 read I/O 时自动从预注册的缓冲池中挑选一个空闲缓冲区，完成 CQE 中通过 buf_id 告知用户态哪个缓冲区被使用。这避免了在发起 read 前分配缓冲区的必要性，对多连接高并发场景意义重大。

五、性能分析

io_uring 相比其他 I/O 模型的性能优势体现在以下维度：

• 系统调用次数：批量提交 N 个请求可只触发 1 次 io_uring_enter，极端情况下 0 次（SQPOLL 持续激活）
• 内存往返开销：传统 I/O 每次调用需要 copy_from_user/copy_to_user，io_uring 通过共享内存和 sqpoll 减少这类拷贝
• 中断上下文切换：IOPOLL 模式下完全绕过中断，CPU 以 busy-poll 方式等待设备完成，比拼速度而非低唤醒
• 锁竞争优化：io_uring 使用单生产单消费者的无锁环形队列，无需 spinlock，cache line 争用最小化

在 NVMe SSD 上的基准测试（fio 工具）显示，io_uring (ioring + iopoll) 可达到较 libaio 2-3 倍的 IOPS 提升，CPU 利用率降低约 50%。

六、内核实现关键路径

从内核源码角度，io_uring 的请求处理路径如下：

1. 用户态触发 io_uring_enter(2) 系统调用（syscall number 425，5.18 起）
2. 进入 io_uring_enter() → io_ring_submit()，将 SQE 提交到 SQ tail
3. 若使用 SQPOLL，SQ 线程 io_sq_thread() 已轮询到该 SQE，执行 io_submit_sqes()
4. io_submit_sqes() 根据 SQE opcode 分发到具体处理函数（io_read()/io_write()/io_connect() 等）
5. 对于 block I/O，最终调用 blk_mq_submit_bio()，进入块设备层排队
6. I/O 完成时触发 CQE 写入 CQ tail，用户态通过 CQ head 变化感知完成

从内核 5.10 起，io_uring 还支持工作队列线程化执行（io-wq），支持任意可能被阻塞的系统调用在 io-wq 线程池中以非阻塞方式执行，从而消除了 io_uring 早期"大多数调用需要 O_DIRECT" 的限制。

七、总结与适配场景

io_uring 的出现标志着 Linux 异步 I/O 正式进入生产可用时代。以下是推荐的应用场景：

• 高并发网络服务器（替代 epoll + 非阻塞 read/write）
• 数据库和 KV 存储引擎（WAL 持久化、SSTable 读取）
• 容器和虚拟化平台的磁盘 I/O 加速
• AI 训练数据 pipeline（大批量小文件读取）
• CDN 边缘节点（高吞吐文件分发）

然而，io_uring 并非银弹。对于简单的、低并发的 I/O 场景，引入 io_uring 带来的内存映射、线程维护开销可能抵消性能收益。理解其架构原理，在合适的场景扬长避短，才是技术选型的正确姿态。