Linux 7.2の主要変更点は？ キャッシュ最適化、高速I/O、新ハードウェア対応を総覧

タスクを別のキャッシュ領域へ頻繁に移すと、キャッシュミスやデータの行き来が増え、処理の効率が落ちる場合があります。そこで関連する処理を近いコアにまとめ、不要なキャッシュ移動を抑えるのが狙いです。AMD EPYCやIntel Xeonのように、複数のチップレットやソケットで構成されるシステムでは、特に効果が期待されます。

ただし、すべてのPCが一律に高速化する機能ではありません。効果はCPUのキャッシュ構成とワークロードに左右されるため、複雑なトポロジーで関連タスクを移動させるオーバーヘッドが大きい環境向けの改善と考えるのが適切です。

ストレージ性能は複数のサブシステムで改善

Linux 7.2の性能向上は、1つのベンチマーク機能に集約されているわけではありません。パイプ、VFS、各種ファイルシステムなど、日常的なI/O経路の複数箇所に分散しています。

• パイプへの書き込みでは、ワークロードやテスト条件により、およそ**6〜28％**のスループット向上が報告されています。
• ext4では、fast commit処理を見直し、ロック競合やデッドロックのリスクを抑える変更が入りました。ディレクトリのハッシュ計算も高速化されています。
• ext4とXFSのiomap関連処理では、NVMe SSDとio_uringを使う高IOPSワークロードで改善が確認されています。ただし、すべてのストレージやアプリケーションで同じ効果が出ることを保証するものではありません。
• Btrfsでは、大きなフォリオのサポートが実験段階を終え、標準で有効になりました。最大2MBの巨大フォリオは、引き続き実験的な機能として追加されています。
• exFATはiomap基盤への移行がさらに進み、バッファードI/O、ダイレクトI/Oなどの処理を改善しました。高負荷テストでは大幅な向上が報告されていますが、結果はワークロードに依存します。

つまり、Linux 7.2の恩恵を受けやすいのは、CPUキャッシュの局所性、ファイルシステムのメタデータ処理、高速NVMeストレージ、プロセス間通信、Btrfsのメモリー管理に負荷がかかる環境です。

Apple M3、USB4STREAM、AMDの新機能に対応

ハードウェア対応も今回の大きな柱です。

Apple Siliconでは、Asahi Linuxの上流化作業により、Apple M3搭載MacBookがメインラインカーネルでシリアルコンソールまで起動できるようになりました。これは重要な対応進展ですが、MacBookの各コンポーネントを含む完成度の高いデスクトップ対応が整ったことを意味するものではありません。

Intel向けには、USB4ケーブル経由でデータストリームを送るプロトコルであるUSB4STREAMのサポートが加わりました。 AMDGPUにはHDMI 2.1 Fixed Rate Link（FRL）の初期対応が入り、AMDのプラットフォームコードでは将来のZen 6に向けた準備も始まっています。

そのほかにも、次のような変更があります。

• Intel XeドライバーのCRIプラットフォームへの初期対応
• NouveauによるGSP経由のNVIDIA GA100計算アクセラレーター対応
• Apple Siliconのバッテリー情報取得の改善
• IBM s390アーキテクチャでのRust対応
• ネットワーク、仮想化、セキュリティ、組み込み機器、電力テレメトリーの拡張

このためLinux 7.2は、性能改善だけでなく、今後のハードウェアを受け入れるためのプラットフォーム整備という性格も強いリリースです。

1万3,000行超の古いコードを削除

Linux 7.2では、i486向けx87浮動小数点エミュレーションコードを1万3,000行以上削除しました。AppleTalkに加え、古いISAおよびPCMCIA ARCnetアダプターのサポートも廃止されています。

x86では、利用可能なタイムスタンプカウンター（TSC）を常に要求するようになりました。現在のx86デスクトップやサーバーは一般にTSCを前提としているため、影響するのは極めて古い、または特殊なハードウェアが中心です。

また、カーネルツリーから非推奨のstrncpy() APIの利用をなくす長期的な整理も完了しました。より意図が明確な文字列処理関数へ置き換えることで、保守性と安全性の向上を図っています。

GPUスケジューラーは安定性を優先してFIFOへ戻る

開発中のLinux 7.2には、GPUジョブの順序付けを改善する新しい「fair」GPUスケジューラーが一時的に含まれていました。しかし、AMDグラフィックスで回帰が発生したため、リリース前にFIFO方式へ戻されました。

これは、より高度なスケジューリングを断念したというより、安定版では予測可能なグラフィックス動作を優先した判断です。開発版に登場した機能が、そのまま正式版で使えるとは限らないことを示す事例でもあります。

9週間の開発サイクルとAIが増やすレビュー負荷

Linux 7.2の開発サイクルは約9週間で、2,100人を超える貢献者が参加しました。マージウィンドウの参加規模として記録的だったと報じられており、コミットの約5％にはAI支援を示す属性が付いていたとする分析もあります。

ここで重要なのは、AIがLinux 7.2の主要機能を独自に書いたという話ではありません。AIツールは、脆弱性の報告、修正案、レビュー指摘、追加修正といった材料の流入量を増やしています。AI支援の分析で見つかった問題に対処するパッチが採用される場合もありますが、提案された変更は最終的に人間のメンテナーやレビュアーが確認しなければなりません。

Linus Torvalds氏が語った、規模の大きい遅い段階の更新が「新しい通常（new normal）」になったという見方は、レビュー基準を下げる賛同というより、開発現場で増えつつある作業量への認識と受け止めるのが自然です。Linux 7.2は予定どおり公開されましたが、終盤の変更量と修正の連鎖は、回帰やパッチ品質を管理する難しさを浮き彫りにしました。

Linux 7.3とUbuntu 26.10の行方

Linux 7.2の公開直後には、Linux 7.3のマージウィンドウが始まりました。約40件のプルリクエストがすでに保留中だったと報じられており、今後数週間で7.3に入る主要変更が固まっていく見通しです。

Canonicalのカーネルチームは、Ubuntu 26.10「Stonking Stingray」のターゲットバージョンとして現時点でLinux 7.2を示しています。Ubuntu 26.10は2026年10月15日のリリース予定で、カーネルフリーズは10月1日に設定されています。

そのスケジュールを考えると、十分にテスト期間を確保しやすいLinux 7.2が有力です。ただし、深刻な回帰や統合上の問題が見つかれば、ディストリビューション側の計画が変わる可能性は残ります。

Linux 7.2への更新を検討するユーザーにとって、重要なのは機能数の多さだけではありません。AMD EPYCやIntel Xeonのような複雑なCPU構成を使っているのか、NVMeやio_uringでストレージを酷使しているのか、Btrfsや新しいデバイスを必要としているのか――自分のハードウェアと用途が、今回の改善点に合っているかを確認することがポイントです。