Linux IO_uring高速化へ遮断回避の新手法

Linuxの非同期入出力基盤であるIO_uringに、大幅な効率改善をもたらす可能性のある変更が提案された。 提案者はLinuxの閉塞領域の保守担当者であり、IO_uringの中心的な開発者であるJens Axboe氏だ。 同氏は2026年9月11日、週末を締めくくる形で一連のRFC小片を公開した。 PhoronixのMichael Larabelはこの動きを同日付の記事で伝え、Axboe氏自身がX上で「crazy」と表現した点を紹介した。 現時点では評価用の提案段階であり、主系列への採用時期は確定していない。

今回の作業の焦点は、カーネル内での遮断動作の扱いにある。 IO_uringは高速な非同期処理を実現する仕組みとして定着してきた。 しかし一部の命令では非遮断経路が存在せず、常に別処理への委譲が発生していた。 Axboe氏はこの委譲費用を削減し、実際に遮断した場合にのみ負担が生じる構造を目指している。 提案が採用されれば、応答遅延と資源消費の両面で利点が生じると見込まれる。

遮断回避を狙う新手法の全体像とは

新手法は遮断の可能性がある要求を最初から別 worker に渡さない点に特徴がある。 要求を呼び出し元の文脈で直接実行し、現実に遮断が生じた場合にのみ代替手段を用いる。 遮断が生じない要求はそのまま完了し、余分な起動処理を回避できる。 遮断が生じた場合も、要求自体を移動させるのではなく実行主体の識別情報を移動させる。 この発想が従来の委譲方式と大きく異なる部分だ。

PhoronixのMichael Larabelは、Axboe氏がRFC文書で動作の概要を説明したと伝えた。 原文の説明は次の記述に集約される。

io_uring issues requests inline with IO_URING_F_NONBLOCK and punts to io-wq when that isn’t possible.

すなわち非遮断で実行できる要求は直接処理し、実行できない要求はio-wqに委譲する。 現行方式は安全性を優先し、非遮断経路を持たない命令を無条件で委譲している。 新方式はこの前提を見直し、遮断の有無に応じた処理を選択する。 呼び出し元が深くカーネル内に入った状態でも破綻しない工夫が加えられている。

従来の非遮断実行と委譲の仕組み

IO_uringはIO_URING_F_NONBLOCKを付けて要求を直接発行する。 直接実行できない場合はio-wqと呼ばれる作業待ち行列の worker に処理を渡す。 fsyncやstatx、openat、末尾にatを伴う一連の命令、拡張属性操作、fadvise、spliceなどは非遮断経路を持たない。 このため従来は無条件で委譲の対象となっていた。 委譲のたびに糸の起動、文脈切り替え、task_workによる完了通知の往復が生じる。

この費用は1回あたりでは小さく見える場合がある。 しかし大量の要求を処理する負荷では無視できない積み重ねとなる。 しかも対象命令の多くは現実には遮断しない場合が多い。 fdatasyncが遮断せずに完了する場合や、statxが目録項目緩衝に命中する場合が例として挙げられた。 O_TMPFILE付きのopenatも同様に直接完了できる可能性が高い。 それにもかかわらず安全性の観点から一律に委譲されてきた経緯がある。

IO_uringはカーネル内での偶発的な遮断を防ぐ必要がある。 偶発的な遮断は応答性の低下や資源の占有を招く。 このため開発者は保守的な設計を選択してきた。 安全性と性能の均衡が今回の提案の中心的な課題だ。 新手法は安全性を維持したまま不要な委譲を除去する狙いを持つ。

投稿者と実行主体を交換する発想

新方式では遮断の可能性があっても要求を遮断方式で直接発行する。 要求が遮断しなければそのまま完了し、委譲費用は発生しない。 要求が現実に遮断した場合にのみ代替処理の費用を支払う構造だ。 課題は遮断発生時点で投稿者が深くカーネル内に入り、要求が積み重ね上に存在する点にある。 この状態では作業自体を別の糸に移動できない。

そこで移動させる対象を作業から識別情報に変える。 投稿作業が遮断した場合、待機中のio-wq workerが利用者から見える識別情報を引き継ぐ。 対象には糸識別子や信号状態、資格情報、実行順序属性、制御群、利用者記録状態が含まれる。 引き継いだ worker はio_uring_enter呼び出しを完了させ、投稿者として利用者空間に戻る。 元の作業はio-wq workerとして要求を完了させ、資源集まりに加わる。

利用者空間からは同一の糸識別子が機構呼び出しから戻ったように見える。 内部では異なるtask_structが応答を返している。 利用者はこの交換を意識する必要はない設計だ。 Axboe氏は同様の試みが約20年前に存在した点にも触れた。 過去の知見を踏まえた再挑戦という側面もある。

性能向上と主系列採用への現状展望

Axboe氏はX上で今回の小片を「crazy」と表現した。 同時に性能測定の図を公開し、「tasty results」と述べた。 PhoronixのMichael Larabelは図の内容を詳細な数値としては伝えていない。 内部構造に関心のない利用者にとっても魅力的な結果だと位置付けた。 具体的な数値はRFC段階の測定に依存し、環境で変動する可能性がある。

主系列への採用時期は確定していない。 Phoronixの記事ではLinux v7.4周期に間に合うかが注目点として挙げられた。 RFCは意見募集を目的とする段階であり、設計の洗練が必要だ。 識別情報の交換は資格や制御群など機微な状態を扱う。 安全性の検証と検討が採用の前提となる。

検証では競合状態や例外経路の確認が欠かせない。 信号処理や権限変更との相互作用も精査の対象となる。 性能向上と正確性の両立が審査の焦点だ。 開発者共同体からの指摘が設計に反映される過程が今後の鍵を握る。 採用されれば高負荷の貯蔵処理や記録処理で恩恵が大きくなると見込まれる。

カーネル高速化の潮流との関連性

カーネル領域では不要な委譲や複写の削減が継続的な課題だ。 IO_uring自体が機構呼び出し回数の削減と効率的な完了通知を目的に導入された。 今回の提案はその延長線上に位置する。 非遮断実行の適用範囲を広げ、現実の遮断に応じた費用負担に変える。 資源の利用効率を高める方向性は一貫している。

同様の最適化は他の領域でも進んでいる。 Linux Cache Aware Scheduling拡張、MySQL最大360%高速化は、緩衝の設定と実行設定の工夫で応用性能を押し上げた事例だ。 カーネル内の小さな挙動変更が応用全体に波及する構造は共通する。 IO_uringの改善も特定の応用に限らず広い負荷に影響する可能性がある。 基盤改良の積み重ねが重要性を増している。

貯蔵装置の高速化も背景にある。 不揮発性記憶装置の遅延は縮小し、程式の負担が相対的に増した。 1回あたりの委譲費用が全体性能を左右しやすくなっている。 高並列の奉仕器や記録基盤では差が顕在化する。 今回の提案はこの構造的変化への対応とも解釈できる。

編集部の見解

短期的影響について述べる。今後3か月から6か月ではRFCへの検討と試験が中心になると見る。識別情報の交換は権限や制御群に触れるため、審査は慎重に進むと見る。性能測定の再現や例外経路の検証が議論を左右すると見る。採用時期の断定は現段階では難しいと評価する。

長期的視点について述べる。1年から3年では非同期基盤の設計思想に波及すると見る。遮断の有無に応じた費用負担は資源効率の改善に直結すると評価する。貯蔵処理や高並列奉仕器での応答安定に寄与すると見る。過去の試みの再検討として記録する価値もあると評価する。

編集部からの問いを示す。識別情報の移動は利便性と厳密性のどちらを優先すべきだろうか。利用者から見えない交換はどこまで許容されるのだろうか。性能向上の実測と安全性の検証を両立させる条件は何だろうか。共同体の審査過程が結論を左右すると見る。

参考

• 「Linux’s IO_uring Sees Some “Crazy” Patches That Deliver Very Nice Improvements」, by Michael Larabel — Phoronix, 2026-09-11T16:21:33.000Z (ARR)
• 元記事URL: https://www.phoronix.com/news/Linux-IO-uring-Crazy-Friday