10月23日、Phoronixが「Linux 7.4 Workqueue Changes Bring A "10 To 100 Times Faster" Optimization」と題した記事を公開した。Linux 7.4にマージされたワークキューの改善によって、大規模サーバー環境でフラッシュ処理が最大100倍高速化されたという内容だ。
192コア・2ノード構成のマシンで、アイドル状態のワークキューフラッシュが毎秒40,000回から420万回へと跳ね上がった。コア数が多いほど改善幅が大きい構造になっており、100コア超のIntel XeonやAMD EPYCが当たり前になりつつある現在のサーバー市場に直接刺さる改善だ。
きっかけはHuaweiエンジニアの報告
この改善の発端は、2025年9月初旬にHuaweiのエンジニアYao Kaiがカーネルメーリングリストに投稿した報告だ。128コアのマシンでXFSのログ書き込み（log force）のたびにワークキューフラッシュが呼ばれ、1回あたり最大64マイクロ秒のオーバーヘッドが発生していることを指摘した。ログ書き込みは頻繁に発生する処理であり、このコストが積み重なることでスループットが低下する。
報告を受けて、長年のLinuxカーネル開発者Tejun Heoが改善を実装し、ワークキューのプルリクエストとしてまとめた。Linuxカーネルのメジャーリリースに向けたマージウィンドウを経て、今回Linux 7.4のGitに取り込まれた。
「使ったキューだけ訪問する」シンプルな発想
そもそもワークキュー（workqueue）とは、Linuxカーネルが処理を非同期に遅延実行するための仕組みだ。割り込みハンドラのように即座に完了できない処理をキューに積んでおき、後からカーネルスレッドが処理する。XFSなどのファイルシステムをはじめ、多くのカーネルサブシステムが日常的に利用している。
従来の実装では、ワークキューをフラッシュする際に「CPU数分のキュー（pwq: per-workqueue）」を全件走査していた。コア数が増えるほど、アイドル状態のCPUのキューを空振りで走査するコストが線形に積み上がる構造だった。
Linux 7.4での変更はシンプルだ。前回のフラッシュ以降に実際に使用されたキューだけを訪問する方式に切り替えた。使用済みキューをリスト管理し、フラッシュ時にはそのリストだけを辿る実装で、アイドルなキューへの空振り走査をまるごとスキップする。これだけで劇的な改善が実現した。
ベンチマーク数値の詳細
192コア・2ノードマシンでの計測結果は以下のとおりだ：
- アイドル状態のper-cpuワークキューフラッシュ：40,000 → 4,200,000回/秒（約100倍）
- アイドル状態のunboundワークキューフラッシュ：450,000 → 4,300,000回/秒（約9.5倍）
- 16スレッドがワークをキューイングしつつフラッシュ（per-cpu）：30,000 → 110,000回/秒（約3.7倍）
- 同条件（unbound）：60,000 → 180,000回/秒（約3倍）
トレードオフも存在する。すべてのpwqがアクティブな「高密度フラッシュ」の状況では、per-cpuキューはほぼ変化なし、unboundキューは15〜20%遅くなる。「使ったキューを追跡する」コストが、全件走査のコストを上回るケースが生じるためだ。ただし、実際のサーバーワークロードで全pwqが同時アクティブになる状況は稀であり、通常のユースケースでは恩恵が勝る。なお、キューへのワーク追加パスは今回の変更対象外だ。
多コアサーバーほど恩恵が大きい
この最適化が特に効いてくるのは、多コア構成のサーバーだ。コア数が増えるほどアイドルなキューを空振りで走査する比率が高まるため、改善幅も大きくなる。XFSのログ書き込みのようにフラッシュ呼び出しの頻度が高いワークロードでは、この改善がダイレクトにスループットへ影響する。
AMD EPYCの第5世代（EPYC 9965X、最大192コア）やIntel Xeon 6など、コア数がさらに増加傾向にある現在のサーバー向けCPU市場を踏まえると、こうしたスケーラビリティ改善の価値は大きい。
詳細はLinux 7.4 Workqueue Changes Bring A "10 To 100 Times Faster" Optimizationを参照していただきたい。
