linux – io_submit和带有O_ASYNC的文件有什么区别

我正在阅读这个 tutorial异步磁盘文件io,但它并没有让我清楚,实际上让我更加困惑.

根据本教程,有两种不同的异步IO模型：

>异步阻塞I / O：使用O_ASYNC打开文件,然后使用epoll / poll / select.
>异步IO：在该文章中使用glibc AIO.因为glibc实现只是通过线程池的模拟,我在这个问题中提到的是kernel AIO,即io_submit.

至少从概念的角度来看,没有什么大不同,真的,io_submit可以让你发出多个io reqeusts,另一方面,使用带有O_ASYNC的read,你可以发出一个带有隐含文件位置的请求.

而guide也提到使用epoll替代Linux AIO：

epoll. Linux has limited support for using epoll as a mechanism for
asynchronous I/O. For reads to a file opened in buffered mode (that
is,without O_DIRECT),if the file is opened as O_NONBLOCK,then a
read will return EAGAIN until the relevant part is in memory. Writes
to a buffered file are usually immediate,as they are written out with
another writeback thread. However,these mechanisms don’t give the
level of control over I/O that direct I/O gives.

使用epoll作为AIO替代品有什么问题？或者换句话说,我们需要一个新的接口io_submit来解决的问题是什么？

解决方法

我认为,io_ * api背后的关键问题是能够通过两个主要措施实现更高的IO吞吐量：

>最小化应用程序IO循环中的系统调用次数.可以提交多个请求批处理,然后,在稍后的某个时间,应用程序可以返回使用io_getevents()一次检查各个请求的结果.重要的是,io_getevents()将返回有关每个IO事务的信息,而不是epoll()在每次调用时返回的模糊“fd x has pending changes”位.
>内核IO调度程序可以依赖请求重新排序来更好地利用硬件.应用程序甚至可以传递一些关于如何使用struct iocb中的aio_reqprio字段重新排序请求的提示.必要的是,如果我们允许重新排序IO请求,我们需要为应用程序提供适当的API来查询,是否已经完成了某些特定的高优先级请求(因此io_getevents()).

可以说,io_getevents()是非常重要的功能,因此io_submit()是一个方便的伴侣,可以有效地使用它.