Linux 7.2 有哪些重大變化？快取、儲存與硬體支援一次看

Linux 7.2 於 8 月 16 日正式發布。這是一個內容相當充實的核心版本，重點集中在更有效率地運用 CPU 快取、改善儲存與檔案系統路徑，以及擴充新硬體支援。同時，這次發布也反映 Linux 核心維護者面對的新問題：AI 輔助工具讓漏洞報告、修補建議與後續修正大量增加，所有內容仍需要人類維護者逐一審查、修正與整合。

最大亮點：快取感知排程

Linux 7.2 新增由 CONFIG_SCHED_CACHE 控制的 Cache Aware Scheduling（快取感知排程）。傳統排程器不一定會區分不同核心與快取區域；新機制則會嘗試把共享資料的工作安排在同一個最後層級快取（Last-Level Cache，LLC）網域內。

這樣做的目標，是減少資料在不同快取網域之間來回搬移造成的快取抖動與快取未命中。對採用多晶粒或多插槽設計的系統尤其有意義，例如 AMD EPYC 與 Intel Xeon 平台。

不過，這不是開啟後所有電腦都會立刻變快的通用開關。實際收益取決於處理器拓撲與工作負載；更精確地說，它是針對「相關工作被分散到不同快取網域，因而產生額外成本」這類情境的排程改善。

儲存與檔案系統：瞄準 I/O 實際瓶頸

Linux 7.2 的效能提升並非集中在單一功能，而是分散於多個 I/O 子系統：

• Pipe 寫入路徑的改動，在不同工作負載與測試設定下，回報吞吐量提升約 6% 至 28%。
• ext4 重新設計 fast-commit 路徑，目標是降低鎖競爭與死結風險，同時加快目錄雜湊處理。
• iomap 相關工作改善 ext4 與 XFS 的部分路徑；測試顯示，在高 IOPS 的 NVMe 與 io_uring 工作負載中可獲得效能提升，但不能視為所有磁碟與應用程式都適用的保證。
• Btrfs 的大型 folio 支援不再屬於實驗功能，現在預設啟用；Linux 7.2 也加入最多 2 MB 的實驗性巨型 folio 支援。
• exFAT 進一步轉換至 iomap 基礎架構，改善緩衝 I/O、直接 I/O 及相關操作。重載測試顯示大幅增益，但實際結果仍取決於工作負載，不能解讀為所有 exFAT 使用者都會得到固定幅度的提升。

因此，Linux 7.2 的效能故事比較像是「多處小至中型改善的總和」。如果你的工作主要涉及 CPU 快取區域性、檔案系統中繼資料、高吞吐量儲存、管線通訊，或 Btrfs 記憶體管理，才比較可能感受到明顯差異。

硬體支援擴展至 Apple、AMD、Intel 與 NVIDIA

這次更新包含多項重要的平台支援里程碑：

• Apple M3 MacBook 現在可透過上游 Asahi Linux 工作，以主線核心啟動至序列主控台。這代表硬體移植工作跨過重要一步，但並不等於所有 MacBook 元件都已具備完整、成熟的桌面支援。
• Intel 新增 USB4STREAM 支援，可透過 USB4 線材傳送資料串流。
• AMDGPU 加入初步 HDMI 2.1 Fixed Rate Link（FRL）支援，AMD 平台程式碼則開始為 Zen 6 系統進行早期準備。
• Intel Xe 驅動程式加入初步 CRI 平台支援；Nouveau 透過 GSP 支援 NVIDIA GA100 計算加速器；Apple Silicon 也獲得電池資訊回報改善。
• Rust 支援擴展至 IBM s390 架構，讓更多平台可以開發以 Rust 撰寫的核心元件。

此外，Linux 7.2 也涵蓋網路、虛擬化、安全性、嵌入式系統與電源遙測等更新，因此它不只是效能版本，同樣也是一次大規模的平台支援擴充。

清理舊程式碼，也正式放棄部分古老硬體假設

Linux 7.2 移除了超過 13,000 行 i486 x87 浮點模擬程式碼，同時刪除 AppleTalk，以及舊式 ISA 與 PCMCIA ARCnet 網路介面卡支援。

x86 核心現在也無條件要求系統具備可用的時間戳計數器（TSC）。現代 x86 桌上型電腦與伺服器普遍早已依賴 TSC，因此這項改動主要影響極為老舊或特殊的硬體，而不是目前常見的系統。

這個開發週期也完成了另一項長期清理工作：核心原始碼樹不再使用已棄用的 strncpy() API，改以更明確的字串處理函式取代。

GPU 排程器因 AMD 回歸問題退回 FIFO

Linux 7.2 在開發期間曾加入新的「公平」GPU 排程器，希望改善 GPU 工作的排序方式。然而，AMD 顯示卡出現回歸問題，開發者最終在正式發布前將該排程器退回 FIFO。

這次回退說明了一個核心開發的重要原則：在開發週期中出現的功能，不代表已經準備好讓所有穩定版使用者採用。對維護者而言，確保圖形行為可預期，比在這一版強行推出更進取的排程模型更重要。

九週開發週期，也凸顯核心樹的維護成本

Linux 7.2 的開發週期約九週，共有超過 2,100 名貢獻者參與，並創下合併視窗參與人數的相關紀錄。報導引述的分析則指出，約 5% 的提交帶有 AI 輔助標記。

這裡的重點不是 AI 自主寫出了 Linux 7.2 的主要功能。更大的變化在於，AI 工具帶來了更多漏洞報告、修補建議、審查結果與後續修正；即使某些最終合併的變更，是為了解決 AI 輔助分析發現的問題，每一項建議仍會為核心維護者與審查者增加工作量。

Linus Torvalds 將大型、延後提交的更新形容為「新常態」，比較像是在承認日益增加的作業現實，而不是認同降低審查標準。Linux 7.2 最終仍按期發布，但後期變更量增加，也凸顯核心團隊為何持續關注程式碼品質、回歸問題與修補程式數量。

Linux 7.3 與 Ubuntu 26.10 接下來怎麼走？

Linux 7.3 的合併視窗在 7.2 發布後隨即開啟，報導指出當時已有約 40 個 pull request 等待處理。接下來幾週的合併結果，將決定哪些主要變更能進入 Linux 7.3。

至於 Ubuntu 26.10，Canonical 核心團隊目前已將 Linux 7.2 列為目標版本。Ubuntu 26.10 預定於 2026 年 10 月 15 日發布，核心凍結時間規劃在 10 月 1 日。以目前時程來看，Linux 7.2 是較成熟的目標，但如果測試發現嚴重回歸或整合問題，發行版計畫仍可能調整。

對核心開發者而言，下一步是持續進行回歸測試與程式碼審查；對一般使用者而言，真正值得關注的不是 Linux 7.2 的功能清單有多長，而是自己的硬體與工作負載是否正好能受益於快取區域性、檔案系統吞吐量、新平台支援，或裝置驅動的改善。