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

Question

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

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

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

至少从概念的角度来看，没有太大的区别，是的，io_submit可以让你发出多个io reqeusts，另一方面，使用带有O_ASYNC的read，你可以发出一个带有隐含文件位置的请求。

此guide还提到使用epoll替代Linux AIO：

  

epoll的。对于使用epoll作为机制，Linux有有限的支持   异步I / O.用于读取以缓冲模式打开的文件（即   是，没有O_DIRECT），如果文件打开为O_NONBLOCK，则a   read将返回EAGAIN，直到相关部分在内存中。写   缓存文件通常是立即的，因为它们是写出来的   另一个回写线程。但是，这些机制并没有给出   对I / O直接输入的I / O控制水平。

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

Answer 1

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

1. 最小化应用程序IO循环中的系统调用次数。可以提交多个请求批处理，然后，在稍后的某个时间，应用程序可以返回使用io_getevents（）一次检查各个请求的结果。重要的是，io_getevents（）将返回有关每个IO事务的信息，而不是epoll（）在每次调用时返回的模糊“fd x has pending changes”位。

2. 内核IO调度程序可以依赖请求重新排序来更好地利用硬件。应用程序甚至可以传递一些关于如何使用struct iocb中的aio_reqprio字段重新排序请求的提示。必要的是，如果我们允许重新排序IO请求，我们需要提供具有适当API的应用程序来查询，是否已经完成了某些特定的高优先级请求（因此io_getevents（））。

可以说，io_getevents（）是非常重要的功能，因此io_submit（）是一个方便的伴侣，可以有效地使用它。