io_uringがコアあたり60%高速化、PoC公開

ジェンス・アクスボーが帰国フライト中に書いたパッチで、Linuxカーネル内I/Oが60%速くなる。SPDKに勝てなくても「相当近づける」と本人は語る。

フライトの中で生まれたパッチ

Linuxカーネルのio_uringとブロック層メンテナを務めるジェンス・アクスボー（Jens Axboe）が、コアあたりのI/O性能を 60% 引き上げる概念実証パッチを公開した。発端は1週間前にクロアチア・ザグレブで開かれたLSFMM+BPFサミット2026だ。

LSFMMはLinuxのストレージ・ファイルシステム・メモリ管理・BPFを担当するメンテナだけが招待される技術ワークショップで、招待制かつクローズドな性格を持つ。その場で「カーネル内I/Oはどこまでユーザー空間バイパスに近づけるか」というセッションがあり、アクスボーはそこから着想を得て、帰国フライト中にPoCを書いた。

最初の発表は5月9日。アクスボーは、コアあたり性能を50%引き上げる概念実証ができたと述べ、続けて同日中に数字を60%まで更新した投稿を上げている。

「SPDKにどれだけ近づけるか」というLSFMMのセッションほど、やる気をくれるものはない。帰りのフライトで概念を仕立てて、コアあたり性能を50%引き上げた。カーネル内ではバイパスを超えられないが、それほど大きな労力でなくとも相当近づける。

50%から60%まで、同日中に数字が伸びている。ここで興味深いのは、アクスボー自身が「カーネル内ではバイパスを超えられない」と認めている点だ。これは謙虚さではなく、長年のLinuxストレージ界が抱えてきた構造の話である。

なぜSPDKが「目標」になるのか

SPDKはStorage Performance Development Kit、つまりIntelが立ち上げ、現在はLinux Foundationに移管された ユーザー空間NVMeドライバ 群だ。カーネルを完全にバイパスし、ユーザー空間からNVMe SSDへ直接アクセスする。ポーリングモードで割り込みを使わず、ロックを使わず、ゼロコピーでデータを動かす。結果として、カーネル経由のI/Oスタックには絶対に出せない数字を叩き出す。

データベースやハイパフォーマンスストレージ製品の世界では、SPDKは事実上の標準ツールだ。代償もある。ユーザー空間ドライバはカーネルが提供する保護機構や汎用性を捨てており、実装も運用も難しい。アプリケーションごとに専用のI/Oスタックを抱えることになる。

カーネル内I/Oの存在意義 は、汎用性と保護にある。誰でも使える、ファイルシステムや権限管理が効く、デバイスドライバを書き直さなくていい。引き換えに、ピーク性能ではバイパス勢に勝てない。

io_uringはこの差を埋めるために2019年（カーネル5.1）に導入された 非同期I/Oインターフェース だった。リングバッファをカーネルとユーザー空間で共有することで、システムコールの回数を最小化する。アクスボーはその主開発者であり、io_uringの登場以降、継続的にカーネル内I/Oを高速化してきた人物だ。

SPDKはユーザー空間でNVMeを直接叩くため、カーネルのオーバーヘッドを完全に除去できる。一方カーネル内のio_uringはファイルシステムや権限の枠の中で動く。両者の差は構造的なもので、ベンチマーク結果が示してきた距離はずっと埋まらないと考えられてきた。

パッチの中身

PoCはgit.kernel.orgの「io_uring-io-slots」ブランチで公開されている。コミットログを見ると、アクスボー本人が短時間に集中して変更を積んだ形跡がある。主な変更は次のようなものだ。

io_uring側に「IOスロット」と呼ばれる新しいインフラを追加し、IORING_OP_SLOT_RW というオペレーションコードを新設する。registered buffer（あらかじめカーネルに登録されたI/Oバッファ）に対して、 永続的なDMAマッピング を持たせ、複数のスロット間で共有する。ブロック層には BIO_REGISTERED フラグと submit_bio_noacct_fast() を追加し、NVMe PCIドライバに登録済みIO向けのDMAマッピング経路を入れる。

アクスボー本人の説明はこうだ。

基本的には、登録済みバッファを拡張して、bio構造体をあらかじめ準備し、DMAマッピングも事前に済ませた状態にする。そしてO_DIRECTの場合はスロットを引いてbioを直接サブミットする。通常の登録済みバッファ経路ではホットパスの中でページ参照とユーザー空間へのマッピングが発生していたが、上記のブランチはそれを回避し、IOホットパスのbioアロケーションとDMAのマップ／アンマップをなくす。

要するに、I/O発行のたびに繰り返される「メモリの参照」「DMAマッピング」「bioの確保」を、登録時に1回だけやって以降は使い回す、という発想だ。ホットパスで何度も繰り返される処理を、初期化時の1回に押し込む形になる。古典的なオーバーヘッド削減のパターンだが、io_uringというフレームワークがあって初めて実装可能になる手法だ。

対象は O_DIRECT を伴うストレージI/Oで、ファイルやブロックデバイスに直接アクセスするワークロードに効く。アクスボー自身がX上の質疑応答で「O_DIRECTでブロックデバイスやファイルを叩くワークロード、つまりストレージワークロード」と説明している。

「ニッチではない」という反論

X上のスレッドでは、ある利用者から「特殊なワークロードでしか効かないのでは」という疑問が投げられた。アクスボーの返事は短い。

That's not a niche workload, fwiw.（念のため言っておくが、それはニッチなワークロードではない）

データベース、特にO_DIRECTを使うMySQL/InnoDBやPostgreSQLのWAL書き込みなどは、まさに対象となる。クラウドのオブジェクトストレージ、分散ファイルシステムのバックエンド、AI学習用の大規模ストレージ、いずれもこの最適化の射程に入る。

数字でいえば60%だが、この60%が コアあたり の数字であることに注意したい。サーバー全体ではなく、1コアでさばけるI/O量が60%増える。マルチコアでスケールするワークロードであれば、システム全体のスループットも比例して伸びる可能性がある。逆に1コアで限界に当たっていたシナリオでは、ハードウェアを変えずに60%余裕が生まれることになる。

メインライン取り込みの先

PoCは現時点でアクスボーの個人ブランチにある。これらのパッチが遠くない将来にメインラインLinuxへ取り込まれることを期待したいが、io_uring関連の大規模変更はレビューに時間がかかる過去がある。NVMe PCIドライバとブロック層、io_uring本体すべてに手を入れる以上、複数のメンテナの目を通る必要がある。

しかし注目すべきは、アクスボーが「それほど大きな労力でなくとも相当近づける」と表現していることだ。彼は2022年に「2Uサーバーで1億2200万IOPS」「1物理コアで1000万IOPS」といった数字をio_uringで叩き出してきた人物で、空想で性能向上を語る立場ではない。コードはすでに動いており、数字はベンチマークで取れている。残るは品質と汎用性のレビューだ。

カーネル内I/Oは、SPDKが切り開いたユーザー空間バイパスにずっと追いつけないと言われてきた。今回のPoCは、その距離を 同日中に10ポイント 縮めるに値する変更だった。SPDKに「勝つ」ことは目標ではない。だがLinuxカーネルがバイパス勢に対してどこまで競争力を保てるかは、io_uringを土台にしたデータベースやストレージミドルウェア全体の未来を決める。

フライトの中で書かれたパッチがメインラインに乗る頃には、I/Oの常識がもう一段ずれているのかもしれない。

参照元

• Jens Axboe - X (LSFMM発端の投稿)
• git.kernel.org - io_uring-io-slots ブランチ

関連記事

• Linux 7.0でPostgreSQL性能半減、修正困難か
• Linux 7.1-rc6、AI修正の波は収まらず
• Linuxカーネルからx32 ABIの削除が始まる
• Btrfsがhuge folios対応、Linux 7.2で投入へ
• IntelがUSB4STREAMをLinuxに導入、ケーブル1本でPC間転送
• トーバルズ氏、AI由来の修正を差し戻すと宣言
• AIが見つけるLinux脆弱性、ネットワーク修正が「終わりの見えない混乱」に
• ssh-keysign-pwn対応Linux 7.0.8公開
• OpenZFS 2.4.2リリース、Linux 7.0に対応
• Fragnesia公開、Linux LPE 2週で3件目