io_submit和O_ASYNC文件有什麼區別

Question

我正在讀這個tutorial異步磁盤文件io，但它並沒有讓我清楚，實際上讓我更加困惑。

有根據本教程中兩個不同的異步IO模式：

1. 異步非阻塞I/O：打開文件與O_ASYNC，然後使用epoll的/調查/選擇。
2. 異步IO：在該文章中使用glibc AIO。因爲glibc的實現只是一個通過線程池的模擬，我在這個問題中提到的是kernel AIO，即io_submit。

在從概念至少點的觀點，也沒有大的區別，真正的，io_submit可以讓你發出多個IO多個請求，而在另一方面，使用與O_ASYNC閱讀，你可以只發出一個涉及文件位置的請求。

這guide還提到，使用epoll的作爲替代的Linux AIO：

epoll的。 Linux有有限支持使用epoll作爲 異步I/O的機制。對於以緩衝模式（ ，沒有O_DIRECT）打開的文件進行讀取時，如果文件被打開爲O_NONBLOCK，那麼 讀取將返回EAGAIN，直到相關部分在內存中。將 寫入緩衝文件通常是立即執行的，因爲它們是用 另一個寫回線程寫出的。然而，這些機制並沒有給出直接I/O給出的I/O的控制級別。

使用epoll作爲AIO替代品的問題是什麼？換句話說，我們需要一個新的接口io_submit來解決什麼問題？

Answer 1

我的意見時，io_ * API背後的關鍵問題是通過兩個主要措施，以實現更高的IO吞吐能力：

1. 的系統的數量在應用IO循環調用最小化。可以提交多個請求批次，然後在稍後的時間，應用程序可以返回以使用io_getevents（）一次性檢查各個請求的結果。重要的是，每次調用時，io_getevents（）都會返回每個單獨的IO事務的信息，而不是一個模糊的「fd x有待處理的更改」位的epoll（）返回的信息。

2. 內核IO調度程序可以依靠請求重新排序來更好地使用硬件。應用程序甚至可以傳遞一些關於如何使用struct iocb中的aio_reqprio字段重新排序請求的提示。必要時，如果我們允許重新排序IO請求，我們需要爲應用程序提供適當的API來查詢，是否某些特定的高優先級請求已經完成（因此io_getevents（））。

可以說，這io_getevents（）是功能，真正重要的一塊，於是io_submit（）是一個方便的伴侶有效地利用它。