liburing项目中的IO轮询性能对比分析：io_uring vs epoll

引言

在现代高性能服务器开发中，I/O多路复用技术是核心组件之一。传统的epoll系统调用已经服务我们多年，而io_uring作为Linux内核提供的新一代异步I/O接口，正在逐渐被广泛采用。本文将基于liburing项目的实际测试数据，深入分析io_uring与epoll在文件描述符轮询方面的性能差异。

测试环境与方法

测试采用了两种不同的轮询模式：

1. 定时等待模式：使用1秒超时的等待方式（如io_uring_wait_cqes()或epoll_wait()）
2. 忙轮询模式：无阻塞的紧密循环检查（如io_uring_peek_cqe()或epoll_wait(0)）

测试平台包括Intel i9-12900F和AMD EPYC 7763处理器，内核版本为6.1。测试程序通过管道进行进程间通信，测量从写入到唤醒的完整延迟周期。

性能数据对比

在Intel i9-12900F平台上，核心测试结果如下（单位纳秒）：

模式	平均延迟	中位数	90%分位	99%分位
io_uring定时等待	4058	3773	4876	7336
io_uring忙轮询	1988	1936	2110	2827
epoll定时等待	4331	4035	5448	7575
epoll忙轮询	1316	1294	1499	1986

当使用IORING_SETUP_COOP_TASKRUN | IORING_SETUP_TASKRUN_FLAG标志时，io_uring的忙轮询性能提升至1505纳秒（平均），接近epoll的水平。

关键发现

1. 常规场景性能相当：在定时等待模式下，io_uring和epoll表现出相似的性能特征，平均延迟差异在可接受范围内。

2. 忙轮询模式差异：epoll在忙轮询模式下表现出约10-20%的性能优势（约100-200纳秒）。这是由于io_uring需要处理任务工作（taskwork），要么通过中断，要么通过系统调用。

3. CPU亲和性影响：当生产者和消费者线程被固定到隔离的"无滴答"核心上时，两种技术的延迟都显著降低，但相对性能趋势保持不变。

io_uring标志位的影响

测试中探索了多个io_uring标志位的组合效果：

• IORING_SETUP_COOP_TASKRUN：避免IPI中断，但不强制用户空间任务进入内核处理任务工作
• IORING_SETUP_TASKRUN_FLAG：与上述标志配合使用
• IORING_SETUP_DEFER_TASKRUN：将任务工作保持私有，仅在等待事件或调用io_uring_get_events()时运行

值得注意的是，COOP_TASKRUN和DEFER_TASKRUN不应同时使用，正确的组合应该是COOP_TASKRUN | TASKRUN_FLAG或DEFER_TASKRUN | SINGLE_ISSUER。

实际应用建议

1. 选择合适的轮询模式：对于主要使用共享内存环进行通信但仍需轮询文件描述符的场景，io_uring的忙轮询模式表现良好。

2. 谨慎使用忙轮询：虽然忙轮询可以减少延迟，但会显著增加CPU使用率，应根据实际需求权衡。

3. 考虑CPU亲和性：对于延迟敏感型应用，将相关线程绑定到特定核心可以显著提高性能。

4. 文件描述符类型选择：管道虽然便于测试，但不能完全代表网络工作负载的唤醒特性，实际应用中应根据使用场景选择合适的IPC机制。

结论

io_uring作为epoll的替代方案，在基本文件描述符轮询功能上表现出与epoll相当的性能。在大多数场景下，两者的差异可以忽略不计。对于特定高性能场景，通过合理配置io_uring的标志位，可以获得接近甚至优于epoll的性能表现。开发者应根据具体应用场景和性能需求，选择最适合的I/O多路复用技术。