6

非同期ディスク ファイル I/O に関するこのチュートリアルを読んでいますが、明確にはなっておらず、実際にはもっと混乱しています。

2 つの異なる非同期があります。チュートリアルによる I/O モデル:

  1. でファイルを開き、 // を使用する非同期ブロッキングI O_ASYNC/ epollO 。pollselect

  2. glibc の AIO を使用した非同期 IO

glibc はスレッド プールを使用して AIO を実装しているため、この質問で「AIO」を使用して言及しているのは、むしろカーネル AIOです。io_submit

少なくとも概念的な観点からは、大きな違いはないio_submitようです。複数の I/O リクエストを発行できますが、 readwithO_ASYNCを使用すると、ファイル位置で 1 つのリクエストを発行できます。

このガイドepollでは、Linux AIO の代替としての使用についても言及しています。

epoll。Linux は、非同期 I/O のメカニズムとしての使用を限定的にサポートしています。epollバッファ モードで (つまり、 なしでO_DIRECT) 開かれたファイルへの読み取りの場合、ファイルが として開かれている場合O_NONBLOCK、関連する部分がメモリに格納されるまで、読み取りは EAGAIN を返します。バッファリングされたファイルへの書き込みは、別のライトバックスレッドで書き出されるため、通常は即座に行われます。ただし、これらのメカニズムは、直接 I/O が提供する I/O の制御レベルを提供しません。

epollAIO の代替として使用する際の問題は何ですか? 言い換えれば、[新しいインターフェイス]io_submitが解決する必要がある問題は何ですか?

4

1 に答える 1

1

私の意見では、io_* API の背後にある重大な問題は、次の 2 つの主要な手段によってより高い IO スループットを達成できることです。

  1. アプリケーション IO ループでのシステム コール数の最小化。複数のリクエスト バッチを送信できます。その後、アプリケーションは、io_getevents() を使用して一度に個々のリクエストの結果を調べるために戻ることができます。重要なことに、io_getevents() は、個々の IO トランザクションに関する情報を返します。呼び出しごとに epoll() によって返される漠然とした「fd x には保留中の変更があります」というビットの情報ではありません。

  2. カーネル IO スケジューラは、要求の並べ替えを利用して、ハードウェアをより有効に活用できます。アプリケーションは、struct iocb の aio_reqprio フィールドを使用してリクエストを並べ替える方法についてのヒントを伝えることさえできます。必然的に、IO リクエストの並べ替えを許可する場合、特定の優先度の高いリクエストがすでに完了しているかどうかを照会するための適切な API をアプリケーションに提供する必要があります (つまり io_getevents())。

io_getevents() は非常に重要な機能であり、io_submit() はそれを効率的に使用するための便利なコンパニオンであると言えます。

于 2013-10-31T03:18:07.213 に答える