Linux 7.3が、現地時間10月18日の正式リリースに向けて最終調整に入っている。Linuxの開発を率いるLinus Torvalds氏は、Linux 7.3-rc7の公開告知で、新たな問題が見つからなければ翌週末に正式版を公開する方針を示しており、10月17日時点ではリリース候補版の段階にある。今回の更新では、SSDへの小さな読み出し要求を効率的に処理する仕組みや、ゲームなど複数のアプリケーションが競合するGPUメモリ（VRAM）の割り当てを改善する仕組みが導入される。新しいハードウェアへの対応だけでなく、既存の機器をより効率よく使うための改良も目立つが、その効果はアプリケーションの負荷やシステムの設定によって異なる。
小さなI/Oを高速化、SSDではなくCPU側の負担を削減
高速なSSDでは、ストレージ自体の性能よりも、読み書きの要求を処理するCPU側の負荷がボトルネックになることがある。ByteDanceのFengnan Chang氏がPCIe Gen5対応NVMe SSDを使って4KiBのランダム読み出しを測定したところ、ストレージを直接扱う条件では約320万IOPSだったのに対し、ext4やXFS上のファイルを読み出す場合は約192万IOPSにとどまった。IOPSは1秒間に処理できるI/O要求の回数を表す指標だ。ext4の内部処理を分析した結果、メモリの確保や、ファイル内の領域とI/Oを管理する共通機構「iomap」の繰り返し処理に、多くのCPU時間が費やされていることが分かった。
この問題に対処するため、Linux 7.3には小さな直接I/O（Direct I/O）に特化した高速処理経路が追加された。直接I/Oは、カーネルのページキャッシュを経由せずにストレージへ読み書きする方式だ。採用されたパッチでは、I/O要求とその管理情報をまとめてメモリに確保し、正常終了時の後処理も簡素化している。Chang氏が単一CPUコアを使用して実施したポーリング試験では、ext4の読み出し性能が約192万IOPSから約219万IOPSへ向上した。
ただし、この高速経路が適用されるのは、ファイルシステムの1ブロックに収まる読み出しなど、特定の条件を満たすI/O要求に限られる。暗号化されたファイルや、中継バッファを必要とする要求は対象外だ。そのため、書き込み処理や大容量ファイルの転送など、あらゆるストレージ操作が同じ割合で高速化されるわけではない。
Chang氏が実施した別の4KiB直接読み出し試験では、ポーリングを使用するio_uringの性能改善率は、QD1で−0.06〜0.54％、QD256で9.76〜10.06％だった。QD（Queue Depth）は、同時に発行するI/O要求の数を表す。測定結果を以下に示す。
| ファイルシステム | キュー深度（QD） | 変更前のIOPS | 変更後のIOPS | 改善率 |
|---|---|---|---|---|
| ext4 | 1 | 19,283 | 19,272 | −0.06% |
| XFS | 1 | 19,211 | 19,315 | 0.54% |
| ext4 | 256 | 1,663,498 | 1,830,842 | 10.06% |
| XFS | 256 | 1,587,339 | 1,742,220 | 9.76% |
この表は、Chang氏がコミットの説明に記載したfioベンチマークから、同じ読み出し方式でQD1とQD256を測定した結果を抜き出したものだ。io_uringはLinuxの非同期I/O機構で、今回の試験ではI/Oの完了を繰り返し確認するポーリング方式を使用している。改善率の範囲はext4とXFSの測定値の違いを示しており、測定誤差ではない。また、前述の192万IOPSから219万IOPSへの改善とは測定方法が異なるため、同じ条件の結果として扱うことはできない。
測定結果を見ると、I/O要求を1件ずつ処理する条件ではほとんど性能が変わらない一方、多数の要求を並行して発行する条件では約10％の改善が見られる。つまり、効果を左右するのはSSDの性能だけでなく、アプリケーションがどの程度I/Oを並列処理しているかという点だ。データベースなどの実際のアプリケーションでは、要求サイズやキュー深度、ほかの処理との兼ね合いも影響するため、この測定結果をそのままシステム全体の高速化率として扱うことはできない。
Btrfsでは直接I/Oと同期処理を改善、特定条件で約5倍の性能向上
Btrfsにも直接I/Oを効率化する変更が加わるが、解決しようとしている問題はext4やXFSの小さな読み出し要求とは異なる。従来のBtrfsには、データの整合性を保つため、直接I/Oからページキャッシュを使用するバッファードI/Oへ切り替える処理経路があった。Linux 7.3では、iomapの中継バッファを利用することで、この切り替えを回避する仕組みが導入される。したがって、Btrfsの直接I/O改善と、前述の小さな読み出し専用の高速経路は、別々の変更として理解する必要がある。
さらに、Btrfsではデータをストレージへ同期する処理についても、不要な待機や検索を削減する改良が行われた。David Sterba氏による更新内容の説明によると、非SSDモードで複数のタスクがログ処理を実行する場合に発生していた、タイマーの1刻みに相当する余分な待機を解消した。その結果、例示されたワークロードではスループットが約5倍に向上したという。
別の変更では、ファイルの変更をストレージへ反映するfsync処理も効率化された。具体的には、データの存在しない領域（ホール）がなく、保存領域が多数に分かれているファイルについて、完全なfsyncの際に不要なホールの検出処理を省略する。この変更により、例示された条件では処理時間が従来の約5分の1に短縮された。どちらも大幅な改善だが、前者は特定モードでの待機時間の削減、後者は特定のファイル状態での検索処理の省略によるもので、Btrfsの読み書き全般が約5倍高速化するという意味ではない。
実際の効果は、アプリケーションがどれほど頻繁に同期処理を実行するか、ファイルがストレージ上でどのように配置されているかによって変わる。また、今回の更新では復旧関連のマウントオプションも変更される。rescue=usebackuprootの使用には読み取り専用でのマウントが必須となり、従来の単独のusebackuprootオプションは削除された。Btrfsを運用している環境では、性能だけでなく、障害発生時の復旧手順も確認しておく必要がある。
VRAMの割り当てを改善、ゲームに必要なGPUメモリを確保しやすく
Linux 7.3では、複数のアプリケーションがGPUのVRAMを使用する際のメモリ割り当ても改善される。これまでの仕組みでは、優先的にVRAMを確保したいアプリケーションがあっても、別のアプリケーションが先にVRAMを使い切っていると、必要な領域を確保できない場合があった。ValveのLinuxグラフィックス開発に携わるNatalie Vock氏が取り組んだのは、こうした状況で保護対象のアプリケーションが不利になる問題だ。
Linuxには、プロセス群のリソースを管理するcgroupと、GPUなどのデバイスメモリを管理するdmemコントローラーがある。しかし、Vock氏のパッチ説明によると、保護されていないアプリケーションが先にVRAMを使い切った場合、共通メモリ管理機構であるTTMは、保護対象のアプリケーションによる新たなメモリ割り当てもGTT側へ回していた。GTTは、GPUからアクセスできるシステムメモリ側の領域を指す。従来の保護機構は、すでにVRAMに存在するデータが退避されることを防げても、新たな割り当てのためにVRAMの空きを確保することはできなかった。
Linux 7.3に取り込まれた変更では、保護対象のメモリ割り当てに失敗した場合、保護されていないバッファを別のメモリ領域へ退避させ、VRAMに空きを作る仕組みが導入される。これにより、先にVRAMを使用していたアプリケーションが必ずしも優先されるわけではなく、設定された保護方針に従ってメモリを割り当てられるようになる。また、保護されていないアプリケーションが保護対象からVRAMを奪い返すことも防ぎ、データの退避と再配置が繰り返される状況を抑える。
もっとも、この変更によってGPUの物理的なVRAM容量が増えるわけではない。限られたVRAMを、どのアプリケーションに優先して割り当てるかを改善する仕組みだ。dmemコントローラーの管理インターフェースには、メモリ領域ごとの保護や上限を設定するdmem.min、dmem.low、dmem.maxが用意されている。ゲームを優先的に保護するには、こうした設定を利用するユーザー空間側の仕組みも必要になる。
DRMサブシステムの更新には、AMDGPUとIntel Xeドライバー向けのdmem退避対応も含まれている。つまり、カーネル側のメモリ管理機構だけでなく、対応するGPUドライバーと保護設定が組み合わさって初めて改善の効果を得られる。Linux 7.3へ更新するだけで、現在プレイしているゲームが自動的に最優先されるわけではない点には注意が必要だ。
Valveの貢献は旧世代AMD GPUや入力機器にも拡大
Valveが関わる改善は、VRAMの管理だけにとどまらない。旧世代のAMD GPUでは、GFX6〜GFX8アーキテクチャにDRMフォーマット修飾子への対応が追加される。DRMフォーマット修飾子は、画像バッファがメモリ上でどのように配置されているかを、描画や表示を担うコンポーネント間で伝えるための情報だ。DRMメンテナーのDave Airlie氏は、古いGPUでWaylandの各種機能を利用できるようにするための変更として紹介している。ValveのTimur Kristóf氏らによる取り組みは、旧世代のハードウェアを現代のLinuxデスクトップ環境で使い続けるための改善にもつながっている。
同じ更新には、GFX8向けのソフトウェアリセット処理の見直しと有効化も含まれる。こちらはGPUに問題が発生した際の復旧処理に関わる変更であり、DRMフォーマット修飾子への対応とは目的が異なる。いずれも古いGPUの使い勝手や互換性を改善するものだが、GPUそのものの演算性能が向上するわけではない。
入力機器については、HIDサブシステムの更新に、2026年版Steam Controllerの初期対応とMSI Clawへの対応が含まれている。カーネルが新しい入力機器を認識し、扱うための基盤が整うことは、Linuxを搭載するゲーム機器の選択肢を広げるうえで重要だ。ただし、初期対応が追加されたからといって、Steam Inputでの設定や各ゲームでの操作がすべて問題なく動作するとは限らない。実際の使用感や機能の対応状況については、引き続き検証が必要になる。
Apple M3シリーズやIntel Nova Lakeにも対応、実用化の段階には違い
新しいハードウェアへの対応では、Apple M3 Pro、M3 Max、M3 Ultra向けの初期デバイスツリーが追加される。デバイスツリーは、CPUや周辺機器などのハードウェア構成をOSに伝えるための情報だ。Sven Peter氏の説明によると、今回追加されたのはCPUコア、割り込みコントローラー、電源状態などの基本的な構成情報で、起動時の画面表示に使うフレームバッファも含まれる。
ただし、初期デバイスツリーの追加は、M3搭載MacでLinuxのすべての機能が利用できるようになったことを意味しない。起動時に画面を表示できることと、GPUアクセラレーションを利用してデスクトップ環境を快適に動かせることは別の段階だ。今回の変更はM3シリーズへの対応を進める基礎となるものだが、日常的に利用できる環境が完成したと判断するのは早い。
一方、IntelのNova Lake-S向けXeグラフィックスドライバーでは、試験的な動作を明示的に許可するためのforce_probeが不要になる。これは、これまで開発・検証が進められてきたハードウェア対応を、既定で有効にする変更だ。Apple M3シリーズのように初期のハードウェア情報を追加する段階とは異なり、Nova Lake-Sでは既存の対応を通常の動作へ移す段階に進んでいる。同じ新ハードウェア対応でも、実用化に向けた進捗には違いがある。
Linux 7.3の改善を評価する際には、こうした変更の目的と適用条件を見極めることが重要だ。ストレージを多用する環境ではI/O要求のサイズや並列度をそろえて性能を測定し、ゲーム環境ではVRAMの保護設定と実際のメモリ退避の挙動を確認する必要がある。新しいハードウェアについても、単に起動できる段階なのか、必要な周辺機能まで利用できる段階なのかを区別しなければならない。今回の更新は、既存のハードウェアでも、処理経路の効率化や適切なリソース管理によって性能や使い勝手を改善できる余地があることを示している。
