Linux 7.4、アイドル時のworkqueueフラッシュを最大100倍高速化

Linux 7.4は、大規模なマシンでアイドル状態のworkqueueのフラッシュを10〜100倍速くする変更をマージしました。Phoronixが2026年10月22日に報じました。カーネル開発者Tejun Heo氏によるこの修正は、Intel XeonやAMD EPYCのような、CPUコア数の多いサーバーを対象にしています。こうしたマシンでは、ファイルシステムの日常的な処理が、待っている仕事が何もないときでもすべてのCPUを確認し、時間を無駄にしていました。

workqueueのフラッシュとは何か

workqueue（ワークキュー）は、小さな仕事をその場で処理せず、バックグラウンドのワーカースレッドに渡すカーネルの仕組みです。ドライバーやファイルシステムが常に使っています。workqueueをフラッシュするとは、すでに積まれている仕事がすべて終わるまで待つことです。

各workqueueは、pool workqueue（pwq）を通じてワーカースレッドとつながっています。pwqは、1つのworkqueueと1つのワーカーのプールを結ぶものです。大きなサーバーでは、存在しうるCPUごとに1つのpwqがあることもあります。

問題の始まりは、以前のカーネルのコミット「workqueue: Make unbound workqueues to use per-cpu pool_workqueues」です。パッチシリーズのカバーレターによると、この変更以降、フラッシュは「存在しうるCPUごとに1つのpwqをたどり、各プールのロックを順に取得します」。workqueueがアイドル状態でも同じです。コア数が増えるほど、フラッシュのたびに無駄な処理が増えていました。

誰が見つけ、どこで問題になったのか

Phoronixによると、Huaweiのエンジニアである姚凱（Yao Kai）氏が9月初めにこのオーバーヘッドを報告しました。問題が出ていたのは、広く使われているLinuxのファイルシステムXFSです。XFSは、ログを強制的に書き出すたびに、自身のworkqueueの1つであるCIL workqueueをフラッシュします。ログの強制書き出しとは、ジャーナルをディスクに書かなければならない瞬間のことです。

報告によると、128 CPUのマシンでは、このフラッシュに毎回最大64マイクロ秒かかっていました。1マイクロ秒は100万分の1秒なので、64は小さく聞こえます。しかし忙しいファイルシステムはログを非常に頻繁に書き出すため、コストが積み重なっていました。

修正では、前回のフラッシュ以降に実際に使われたpwqを、ノードごとのリストで記録します。ノードとは、専用のローカルメモリーを持つCPUのグループです。フラッシュは今後、そうしたアクティブなpwqだけを訪れます。シリーズは2つのパッチ、「workqueue: Maintain pwq->total_in_flight」と「workqueue: Make flush_workqueue() visit only pwqs active since the last flush」で構成されています。

ベンチマークの数字

パッチシリーズは、2ノード・192 CPUのマシンでの結果を報告しています。per-cpuのworkqueueは決められたCPUで仕事を実行し、unboundのworkqueueはスケジューラーが任意のCPUを選びます。

2ノード・192 CPUのサーバーでのテスト	変更前	変更後
アイドル状態のper-cpu workqueueのフラッシュ	毎秒4万回	毎秒420万回
アイドル状態のunbound workqueueのフラッシュ	45万	430万
16スレッドでキュー投入とフラッシュ（per-cpu）	毎秒3万回	毎秒11万回
16スレッドでキュー投入とフラッシュ（unbound）	毎秒6万回	毎秒18万回

トレードオフもはっきり書かれています。「すべてのpwqがアクティブな密なフラッシュは、per-cpu workqueueでは変わらず、unboundでは15〜20%遅くなります」と、Heo氏はコミットメッセージに書きました。Phoronixがこれを引用しています。新しい仕事をキューに入れる処理には影響しません。

この修正は、すでにメインライン以外にも広がっています。9月9日、姚凱氏は2つのパッチのバックポートをopenEulerのカーネルメーリングリストに投稿しました。対象はopenEulerの6.6ベースのカーネルです。

Linux 7.4は今回のマージウィンドウで、ほかの高速化も取り込んでいます。たとえばテストでファイルオープンを39%速くしたパッチや、サーバーのRAMを節約するIntel TDXのDynamic PAMTです。

開発者にとっての意味

ほとんどの人がworkqueueのフラッシュを直接呼ぶことはありません。大規模サーバーのファイルシステムやドライバーを通じて、この変化を感じることになります。

• コア数の多いマシンでXFSを測り直してください。 CPUが100個以上あるサーバーでXFSを使っているなら、ログを多く書く処理をLinux 7.4と現在のカーネルで比べてください。ディスクへの同期が多い処理が、確認すべきポイントです。
• 混雑時のフラッシュのコストを確認してください。 すべてのpwqが忙しい状態でunbound workqueueをフラッシュするコードは、15〜20%遅くなることがあります。そうしたホットパスを持つカーネル開発者は、変更の前後でベンチマークを取るべきです。
• 小さなマシンでの効果は期待しないでください。 効果は、アイドル状態のpwqを飛ばすことから生まれます。コア数の少ないノートPCには、飛ばせるものがほとんどありませんでした。
• ディストリビューションのカーネルを見守ってください。 openEulerはすでに、このシリーズを6.6カーネルにバックポートしています。ほかのエンタープライズ向けディストリビューションも続くかもしれません。7.4に移行できない場合は、各社の変更履歴を確認してください。