io_uring 是 Linux 下高性能的异步 IO 框架,网上很多相关资料,我之前也初步分析了一下它的实现,有兴趣的可以查看 https://zhuanlan.zhihu.com/p/387620810。
Libuv 中最近加入了对 io_uring 的支持,那么为什么要把它引入 Libuv 呢?因为 epoll 不支持普通文件的 Poll 能力,所以在 Libuv 中,异步文件 IO 操作需要通过线程池来实现,具体来说就是当用户发起一个异步文件 IO 操作时,Libuv 会把这个操作放到线程池中,当子线程处理这个任务时,会执行一个阻塞式的系统调用,这个系统调用会引起线程阻塞,从而导致这个线程被消耗掉了,当 IO 操作完成后,子线程就会被唤醒,子线程再通过主线程去执行用户的回调。在 Libuv 早期的实现中,如果执行比较慢的任务过多就会把线程池中的线程消耗完,从而导致执行比较快的 IO 操作需要等待很长时间,一个例子就是 DNS 解析会阻塞文件 IO 任务。而 io_uring 可以支持普通文件 IO(当然能力不仅于此),不再需要借助线程池的能力,目前 Libuv 中部分异步文件 IO 操作已经替换成 io_uring(需要通过环境变量开启),下面来看看它的实现。
原生 io_uring 的使用比较复杂,通常需要借助 liburing 库,但是 Libuv 中可能为了减少对第三方库的依赖,实现上使用原生的方式。
io_uring 初始化
在 Libuv 初始化时会进行 io_uring 的初始化。
lfields->iou 为 io_uring 核心结构体,UVIORING_SETUP_SQPOLL 设置内核创建线程轮询是否有任务需要处理(用户层设置),接着看看 uviou_init。
uv__iou_init 完成了 io_uring 的初始化,并且把 io_uring 对应的 fd 注册到 epoll,当 io_uring 有任务完成时,就可以通过 epoll 感知到。接着就可以使用 io_uring 了。
提交异步任务
下面看一个异步文件 IO 的操作。
uv_fs_open 可以以异步的方式打开一个文件,之前时通过线程池实现的,加入 io_uring 后,就会多了一层拦截,来看看 uv__iou_fs_open。
uviou_fs_open 中有两个核心逻辑 uviou_get_sqe 和 uviou_submit,首先来看 uviou_get_sqe。
uviou_get_sqe 主要是从任务队列中获取一个空闲节点并关联上请求上下文结构体,uviou_get_sqe 的调用方需要设置操作上下文,比如操作类型,操作的 fd 等。通过 uviou_get_sqe 获取任务节点并设置了操作上下文后,这个任务就会自动被操作系统感知。因为 Libuv 是使用了 UVIORING_SETUP_SQPOLL 模式,所以还需要判断这时候内核轮训线程是否处于睡眠状态,这就是 uv__iou_submit 的逻辑。
这样就完成了任务的提交。
任务完成
任务完成后,io_uring 对应的 fd 就会变成可读,从而 epoll 就会感知到,来看看 epoll 的处理。下面是 epoll 处理就绪 fd 时的一段逻辑。
如果是 io_uring 的 fd 可读,则执行 uv__poll_io_uring。
uv__poll_io_uring 的逻辑很简单,就是遍历完成队列,然后拿到对应的请求上下文结构体,最后执行它的回调。
现代软件中大多数使用的 IO 模型是 epoll,随着 io_uring 的发展和成熟,io_uring 将会出现在更多的软件中,之前我也体验了一下 io_uring,有兴趣的可以体验下 https://github.com/theanarkh/nodejs_io_uring。