Linux 7.2 合併視窗前半段：快取感知排程終於合入、Rust zerocopy 加速去除 unsafe、io_uring 儲存大幅翻新
LWN.net · 2026-06-18
Linux 7.1 於 2026 年 6 月 14 日正式釋出後，Linus Torvalds 隨即開啟 7.2 的兩週合併視窗。截至 6 月 18 日，主線已累積超過 7,000 筆非合併 changeset，多數核心子系統已完成匯入，涵蓋排程器、儲存堆疊、Rust 生態與硬體平台支援。合併視窗預計於 6 月 28 日關閉，發布 v7.2-rc1，正式版預估 2026 年 8 月中下旬釋出。
核心改動一：Cache Aware Scheduling 終於落地
排程子系統此次合入了醞釀逾一年、由 Intel 工程師主導開發的 Cache Aware Scheduling（CAS），由排程維護者 Peter Zijlstra 透過 sched/cache 分支合入主線。這是近年來針對現代伺服器 CPU 最重要的排程改進之一：核心在任務遷移決策時感知 末層快取（LLC）邊界，盡量將頻繁共享資料的執行緒固定於同一 LLC domain，以降低跨域的快取一致性流量與互連延遲。
實作以 CONFIG_SCHED_CACHE（預設關閉）新增核心選項，並提供執行期切換路徑：
/sys/kernel/debug/llc_balancing/enabled此 debugfs 開關可無需重開機直接進行 A/B 效能比較。現代處理器的多 LLC 分片場景正是 CAS 的主要對象：
- AMD EPYC Turin：多個 Core Complex Die（CCD），各有獨立 L3 快取
- Intel Xeon 6 Granite Rapids：多 tile 設計，每 tile 持有獨立 LLC 區域
- ARM 多叢集伺服器設計（同樣面臨跨叢集 LLC 失效問題）
初步基準測試顯示 AMD EPYC Turin 效能改善最為顯著，Intel Xeon 6 同樣有正向增益，且未觀察到主要排程迴歸。MPI、資料庫執行緒、DPDK 封包處理與 AI 推論後端是預期受惠最大的工作負載類型。
同次合入的排程改動還包含：sched_ext 可延伸排程器新增 cgroup 子排程器支援（每個 control group 可掛載各自的 BPF 排程邏輯）、SD_ASYM_CPUCAPACITY 對 SMT 的感知優化，以及 cfs_rq/sched_entity 資料局部性分配改善。這批排程改動共同指向一個方向：讓核心排程器在拓撲越來越複雜的現代 CPU 上做出更接近最佳解的決策。
核心改動二：儲存堆疊全面更新
io_uring 在此次視窗中重構了 task_work 基礎架構以提升整體吞吐，並強化了 零複製接收（ZCRX） 的使用者空間通知機制——ZCRX 透過 NIC 的 header/data split 功能，將 L4 負載直接落入 userspace mmap 緩衝區，完全繞過核心複製路徑。IORING_OP_CONNECT 新增 opcode 過濾支援，已登記緩衝區管理也獲強化。
NVMe 方面，新增 per-controller admin 與 I/O timeout sysfs 屬性，MD RAID 程式碼改善了 PCI P2PDMA（Peer-to-Peer DMA）沿多路徑裝置的傳播，減少不必要的記憶體複製。Device Mapper 則引入 dm-inlinecrypt 目標，專為行內區塊加密設計，相較傳統 dm-crypt 大幅降低加解密路徑的 CPU 開銷。
核心改動三：Rust zerocopy 與 AutoFDO
Rust 子系統此循環新增超過 40,000 行程式碼，最重要的是引入 zerocopy crate，讓核心程式碼得以消除更多 unsafe Rust 區塊——特別是處理記憶體佈局與型別轉換的場景。AutoFDO（Automatic Feedback Directed Optimization）支援同步落地，使 Rust 核心程式碼可在編譯期利用效能剖析資料最佳化，縮小與 C 語言編譯路徑的效能差距。
影響範圍
硬體支援方面，Apple M3 初步支援、AMDGPU HDMI 2.1 FRL（Fixed Rate Link）以及 USB4STREAM 均列入本次合併視窗的預期項目。Torvalds 在公告中提及因出差網路有限，本次合併視窗採取不規則收件排程，開發者投遞時序需特別留意。v7.2 正式版預計 2026 年 8 月中下旬釋出，Fedora 43 與 Ubuntu 26.10 均預期搭載此版本。
原始來源：LWN.net — The first half of the 7.2 merge window、Phoronix — Cache Aware Scheduling Merged For Linux 7.2、Phoronix — IO_uring, NVMe & Other Block + Device Mapper Changes Merged For Linux 7.2、Phoronix — Linux 7.2 Introducing The Rust Zerocopy Library
單跳區塊複製新方案 RMR 與 BRMR：以 RDMA 多播為雲端持久磁碟降低延遲
LWN.net · 2026-06-18
在 2026 年 Linux 儲存、檔案系統、記憶體管理與 BPF 峰會（LSFMM+BPF Summit）上，開發者 Jia Li 與合作者提出兩個新核心模組：RMR（Reliable Multicast over RTRS） 與 BRMR（Block device over RMR）。這組方案建構於現有的核心 RDMA 傳輸函式庫 RTRS 之上，目標是為雲端供應商提供一種以最低開銷暴露持久化虛擬區塊裝置的途徑。目前兩個模組尚未進入主線，仍在向社群徵求早期回饋。
問題背景：RDMA 缺乏區塊語義，傳統方案多一跳
RDMA（Remote Direct Memory Access）允許叢集內伺服器直接讀寫彼此記憶體，繞過 CPU 與作業系統核心，帶來極低延遲與極高吞吐。然而，裸 RDMA 不提供區塊裝置所需的持久性（durability）與排序（ordering）保證。傳統解法如 DRBD 採用雙跳（two-hop）路徑：寫入先落至主端本地磁碟，再同步至副本，兩段延遲疊加。對雲端 IaaS 規模的虛擬磁碟服務而言，這個額外一跳在高 IOPS 場景下代價可觀。
核心改動：RMR 多播語義與 BRMR 區塊介面
RMR 在現有 RTRS 基礎上加入了可靠多播語義：一次寫入透過 RDMA 同時扇出至多個副本節點，所有節點回傳確認後方視為完成，實現原子性扇出。RTRS 本身已提供連線管理與基本訊息傳遞，RMR 在其上補充群組成員管理、序號追蹤與重傳機制，維持有序傳遞。
BRMR 則是建構在 RMR 之上的區塊裝置驅動層，向上提供標準 Linux block device 介面（struct block_device_operations），向下透過 RMR 將每筆寫入同步複製至所有副本節點，讀取則就近從主端或副本端取回。這個設計實現所謂「單跳（single-hop）複製」：
用戶端 ──RDMA multicast──► 副本節點 A（持久化）
├──────────► 副本節點 B（持久化）
└──────────► 副本節點 C（持久化）
▲ 所有副本 ACK 後方回應完成，省去中間轉發節點相較雙跳方案，理論端對端寫入延遲可減半，因為不再需要主端本地落盤後再轉發的中間步驟。
與現有 RNBD/RTRS 的定位差異
現有的 RNBD（RDMA Network Block Device）與 RTRS 已自核心 5.14 合入主線，提供點對點的 RDMA 區塊存取，適用於儲存伺服器集中化場景。RMR/BRMR 的定位不同：面向的是需要跨多節點同步複製的高可用虛擬磁碟場景，例如雲端 IaaS 平台的持久磁碟服務（類似 AWS EBS 或 Google Persistent Disk 的架構需求）。兩者可共存，RTRS 作為共用傳輸層，無需重複實作底層連線管理。
影響範圍與進度
此方案目前仍處於社群討論與概念驗證階段，尚未提交正式 upstream patch series。峰會發表的目的在於收集核心儲存與 RDMA 維護者的早期反饋，確認設計方向後方進入正式 RFC 流程。若順利進入主線，雲端供應商可在核心態直接獲得低延遲、高吞吐的區塊複製原語，無須借助使用者態代理（如 Ceph 的 librbd 或 iSCSI target），預期可顯著降低虛擬磁碟服務的 CPU 佔用與端對端寫入延遲。
原始來源：LWN.net — Single-hop block replication with RMR and BRMR、kernel.org — RNBD/RTRS 說明文件、LWN.net — RTRS 原始介紹（v8 patch series）