高性能I/Oモデル（epoll・io_uring）の内部

なぜ高速I/Oモデルが要るのか

C10K問題（1万同時接続）以降、サーバーは「1接続=1スレッド」では立ち行かなくなりました。スレッドはスタックとスケジューリングのコストが重く（/os/process-thread/ 参照）、数万本も走らせれば文脈切り替えだけでCPUが溶けます。そこで主流になったのが、1つのスレッドで多数のfd（ファイルディスクリプタ）を監視し、準備できたものだけ処理する I/O多重化です。本記事は、その実装が select → epoll → io_uring とどう進化し、各段階で何が遅さの正体だったかを内部から解剖します。

select/poll のO(n)問題

select/poll の使い方は「監視したいfdの集合を渡す → 何か起きたら戻る」です。一見便利ですが、その内部には3つの構造的コストがあります。

1. 毎回のコピー：呼び出すたびに、監視対象fd集合をユーザー空間からカーネルへコピーする。1万fdなら毎回1万件分。
2. 全走査（スキャン）：カーネルは渡されたfdを全部チェックして、どれがレディか調べる。準備できたのが1個でも全件見る。
3. 戻り後の再走査：戻ってきた後、アプリ側も全fdを舐めてどれが立ったか探す。

つまり「実際にイベントが起きたfdの数」とは無関係に、監視対象の総数 n に比例した仕事（O(n)）が毎回発生します。アイドルな接続が大半でも、その全員分のコストを払い続ける——これがC10Kでの致命傷でした。

epoll：レディリストという発想

epoll の核心は、監視対象を一度だけ登録し、カーネル内部に状態を持たせることです。APIは3つに分かれます。

int epfd = epoll_create1(0);                 // epollインスタンス生成
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);     // 監視fdを登録（一度だけ）
int n = epoll_wait(epfd, events, maxev, -1); // レディなものだけ受け取る

内部では、登録されたfdは赤黒木（バランス木）で管理され、追加・削除・検索が O(log n) で行えます。ここが「毎回コピー」を不要にする土台です。そして決定的なのがレディリストの存在です。

• 各fdの基になるデバイス／ソケットには、データ到着などのイベント時に呼ばれるコールバックが仕掛けられている。
• イベントが起きると、そのコールバックが当該fdをレディリスト（連結リスト）に繋ぐだけ。
• epoll_wait は、このレディリストを見るだけで「準備できたfd」を返せる。空ならスリープし、イベントで起こされる。

結果、epoll_wait のコストは監視総数 n ではなく、実際にレディになった数 k に比例します。9999接続がアイドルで1接続だけ来ても、仕事はその1件分。これがO(n)の呪縛を断ち切った正体です。データ到着の「向こうから知らせる」非同期通知は/os/interrupt-io/ の割り込み機構が土台になっています。

エッジトリガ（ET）とレベルトリガ（LT）

epoll が登録時に選べる、いつ通知するかの2方式です。ここはバグの温床なので原理を正確に。

• レベルトリガ（LT, デフォルト）：「いま条件が成立している限り」通知する。受信バッファにデータが残っていれば、読み切るまで epoll_wait は毎回そのfdを返す。状態（レベル）を見る。
• エッジトリガ（ET）：「状態が変化した瞬間だけ」通知する。新たにデータが到着したそのとき1回だけ返り、まだ未読データが残っていても次は返さない。変化（エッジ）を見る。

受信:   [   ] →データ到着→ [####] →一部読む→ [##] →残りはそのまま
LT通知:               ●           ●(まだある)   ●(まだある)…毎回
ET通知:               ●            (変化なし→通知なし)

ETでは「通知された1回」で、そのfdを EAGAIN/EWOULDBLOCK が返るまで読み切る／書き切る のが鉄則です。途中でやめると残りデータの存在を知らせる次の通知が来ず、そのfdが永久に固まることがあります。当然、対象fdはノンブロッキングでなければループ自体がブロックします。

なお ET は通知回数が減るぶん epoll_wait 往復を節約できますが、性能差より正しさの担保のしやすさでLTを選ぶ設計も現実には多くあります。

io_uring：システムコールという最後の壁

epoll でも、実際の read/write 自体は依然システムコールです。1イベントごとにユーザー↔カーネルのモード切替が走り、その固定コストは/os/system-call/ のとおり無視できません。さらに epoll は「準備できたか」を教えるだけで、データのコピーはアプリが別途呼ぶ通知モデルにとどまります。

io_uring はこの構図を完了モデルへ転換します。鍵は、カーネルとユーザー空間で共有メモリ上に置いた2本のリングバッファです。

• SQ（Submission Queue）：アプリが「やってほしいI/O（read/write/accept/sendなど）」をSQEとして書き込むリング。
• CQ（Completion Queue）：カーネルが完了結果をCQEとして書き込むリング。

ユーザー空間                 共有メモリ               カーネル
   │  ①SQEを書く  ───────→ [ SQ ring ] ───────→  ②I/Oを実行
   │                                               │
   │  ④CQEを読む  ←─────── [ CQ ring ] ←───────  ③完了を書く

この共有リングのおかげで、I/Oの依頼も結果回収もメモリ書き込み／読み出しだけで済み、引数のコピーが原理的に不要になります。発行をまとめて1回の io_uring_enter で投入すれば、多数のI/Oを1システムコールにバッチ化できます。

ゼロシステムコールの原理（SQPOLL）

さらに踏み込んだのが SQPOLLモードです。カーネル側に専用スレッドを常駐させ、それがSQリングを自分でポーリングします。

• アプリはSQEを書き、リングの末尾（tail）ポインタを進めるだけ。io_uring_enter すら呼ばない。
• カーネルスレッドがtailの変化に気づき、新規SQEを勝手に拾って実行する。
• 完了はCQリングに積まれ、アプリはCQのhead/tailを見るだけで回収する。

定常状態では、I/Oの発行も回収もシステムコールゼロになります。これが「ゼロシステムコールI/O」の正体で、モード切替コストそのものを消し去ります。割り込みすら抑えてポーリングで回す思想は、高速NICのNAPIと同じ系譜です。

まとめ