Linux 7.4で読取オープン39%高速化へ

Linuxカーネルの次期版である7.4に向け、読取目的のファイル開放処理を高速化する改修が提案された。 仮想ファイルシステム層のdo_open処理における重複作業を省く内容である。 PhoronixのMichael Larabelの報道では、同一ファイルの読取専用開放試験で毎秒処理件数が39%増加したと伝えた。 3ダース程度の規模の修正でありながら、効果は大きい。 正式なVFS subsystemの分岐に取り込まれた段階にある。 2026年末までの安定版への収録が見込まれる状況だ。

重複参照を排した開処理の改修点

今回の改修は、経路名探索を伴うファイル開放処理の効率化を狙ったものである。 中心となるのはVFS層のdo_open関数である。 この関数は、経路要素を索引接点に対応付ける探索処理の一部を担う。 開発者のMateusz Guzikが2年以上にわたり改良を主導した。 現行実装では、終端の目録項目に対する参照取得が重複していた。 目録項目はdentryと呼ばれ、経路と索引接点の対応関係を保持する構造である。

改修前の流れでは、__legitimize_pathで終端dentryの参照を確保する。 続くdo_dentry_openでもう一度参照を取得する。 最後にterminate_walkで最初の参照を解放する。 この取得と解放の往復は、実質的な意味を持たない操作であった。 修正版では、既に保持している参照をdo_dentry_openが消費する。 余分な参照計数操作2回分を削減できる設計である。

Guzikは修正の説明で処理の重複を具体的に示した。

Opening a file grabs a reference on the terminal dentry in __legitimize_path(), then another one in do_dentry_open() and finally drops the initial reference in terminate_walk(). That’s 2 modifications which don’t need to be there – do_dentry_open() can consume the already held reference instead.

参照計数は多重処理環境で競合を招きやすい処理である。 計数更新の削減は、錠の取得や緩和 barriers の低減につながる。 命令数は少なくとも、並列時の待ち時間への影響は無視できない。 単純な整理に見えて、核部分の負荷を直接下げる内容と評価できる。

20コア仮想環境における検証結果

性能の検証にはwill-it-scaleの開放試験が用いられた。 20中核の仮想機械上で同一ファイルを読み出し専用で開く条件である。 結果として、毎秒の操作件数は39%増加した。 反復開放を連続実行する微視的試験の数値である。 実業務の処理全体が39%速くなる意味ではない。 それでも、開放経路の寄与が大きい用途では差が表れる可能性がある。

読み出し専用開放の反復は、台本実行や構成管理で頻発する。 コンテナ基盤では起動時に大量の共有資源が開かれる。 言語実行環境も起動時に多数の模索と開放を繰り返す。 記録蓄積や検索基盤も読み出し側の開放を多用する。 こうした用途では、核内経路の短縮が積算で効く可能性がある。 特に中核数が多い機械では、参照計数競合の緩和が効きやすい。

今回の結果が意外な点は、対策の単純さにある。 高度な算法や資料構造の変更を伴わない。 参照の受け渡し方法を整理しただけである。 それにもかかわらず、4割近い伸びが確認された。 長年にわたり見過ごされてきた残存処理の存在を示す事例である。 微視的試験の最適化が実利用でも再現するかは、追加検証が必要な領域だ。

VFS経由で統合へ向かう実装状況

この最適化は一朝一夕にまとまったものではない。 2年以上の検討を経て、5回の改訂を重ねた。 並行処理時の安全性や参照寿命の扱いが論点となったと見られる。 終端項目の寿命保証と探索終了処理の整合性が重要である。 参照を消費する方式では、誤解放や二重解放を避ける必要がある。 例外経路を含めた参照所有権の明確化が求められる。

修正の規模は3ダース行程度とされる。 変更範囲は限定的であり、審査と試験は進めやすい部類である。 現在はVFS.gitのvfs-7.4.lookup分岐に置かれた。 7.4向け素材としての位置付けが明確になった段階だ。 今後の統合窓での主要分岐への申請が見込まれる。 順調に進めば、2026年末までに安定版に届く見通しである。

Linuxの開発過程では、統合窓での選抜と試験を経て安定版が定まる。 性能改修は機能追加と異なり、退行の有無が重視される。 微視的試験に加え、実負荷での安定性確認が欠かせない。 分岐への収録は、その過程に入ったことを示す段階と見るのが妥当である。 利用者側は、配布版への逆移植方針にも注意が必要になる。

安定版供給と運用現場への波及効果

読取開放の高速化は、基盤全体の応答性に影響する可能性がある。 利用者過程の起動時間や台本処理の遅延に関わるためである。 高密度なコンテナ設定では、開放処理の競合が顕在化しやすい。 読取中心の作業負荷では、積算効果が測定可能になる場合がある。 一方で、書込や転送が支配的な用途での寄与は限定的である。 記憶装置自体の速度が上限となる場面も多い。

基盤性能の改善は、応用層の体験を下支えする要素である。 当サイトではApple Intelligence本格始動、iOS 27でSiri AI刷新へで端末側の知能化の動向を扱った。 応用機能の拡張は、裏側の入出力効率に依存する部分が大きい。 X、収益分配を「Original Content Rewards」に刷新 9月8日導入が示す投稿基盤の運用でも、読取処理の安定性は重要である。 Rippling、AI支出追跡ツール『AI Spend Console』発表にあるような運用管理基盤でも同様である。 核部分の残存処理の削減は、こうした層の信頼性向上に寄与すると見るのが自然である。

運用担当者は、7.4の統合状況と配布版の対応表を追うのが望ましい。 微視的試験の39%をそのまま容量計画に織り込むべきではない。 自前の作業負荷での開放頻度と中核数を把握する必要がある。 読取開放が多い系統では、更新後に遅延分布の変化を確認するとよい。 効果が限定的な系統では、他の隘路の解消を優先する判断が妥当である。

編集部の見解

短期的影響について見る。今後3か月から6か月では、7.4統合窓での採否が焦点になると見る。採用されれば、各配布版の試験版を通じて退行確認が進むと見る。読取集中型の基盤では、検証環境での再測定が活発化すると見る。容量計画の前提が変わるほどの即時効果は限定的と評価する。

長期的視点では、VFS層の残存処理の見直しが広がると見る。今回のような参照受け渡しの整理は、他の系統呼び出しにも応用できると見る。コンテナ高密度化の進展により、微視的改修の積算価値は増すと評価する。核内部の競合削減は、電力効率の改善にも波及すると見る。

編集部からの問いを示す。39%という数値は特定条件の結果であり、実負荷での再現性は未検証ではないだろうか。書込開放や特殊なファイル系統でも安全性は保たれるのだろうか。2年間残存した理由として、試験網や所有権規約の課題はなかったのだろうか。利用者側の実測共有が今後の判断材料になると考える。

参考

• 「Simple Optimization For Linux 7.4 Can Open Files For Reading ~39% Faster」, by Michael Larabel — Phoronix, 2026-09-19T16:28:05.000Z (ARR)
• 元記事URL: https://www.phoronix.com/news/Linux-7.4-Faster-Do-Open