Linux 7.3 改善 VRAM 不足時的效能 （★ 130 分）
Linux 7.3 將納入一批改善 GPU（圖形處理器）顯示記憶體管理的修補程式，目標是讓遊戲即使超額使用 VRAM（顯示記憶體），也不至於立刻當機或出現災難性卡頓。當 VRAM 不足時，部分資源必須移到 CPU 的系統記憶體，GPU 再經由 PCIe（Peripheral Component Interconnect Express，高速周邊匯流排）讀取；這不僅延遲較高，頻寬也遠低於 VRAM。以 PCIe 4.0 x16 為例，若要維持每秒 30 影格，每一影格最多只能從系統記憶體搬運約 1 GiB 資料。不過，只要被移出的資源存取頻率低、快取命中率高，或實際使用範圍很小，效能損失未必如預期嚴重。
作者發現，現有 AMDGPU 驅動在嚴重 VRAM 壓力下，問題不只變慢，還可能因提交 GPU 指令時發生鎖定衝突而回報記憶體不足。根源是多個提交作業同時搬移記憶體時，可能形成 ABBA 死結；核心本應中止並重試其中一方，但 TTM（Linux GPU 記憶體管理層）未完整採用 `drm_exec` 的重試機制，導致驅動直接拒絕提交。另一個棘手情況是顯示輸出用的 scanout 影像必須放在連續的實體 VRAM 位址；當 VRAM 碎片化時，核心可能為了一張約 32 MiB 的顯示影像，竟搬走高達 4 GiB 的其他資料，造成遊戲與桌面合成器反覆把相同緩衝區搬進搬出，形成效能極差的「乒乓」現象。
為降低這類震盪，修補程式加入分階段節流：程式資源剛被移出 VRAM 時，先暫停搶回；接著只使用可用空間回收資源、不驅逐其他程式；確認記憶體狀態穩定後才解除限制。作者以《Indiana Jones: The Great Circle》測試，在 8 GiB VRAM 的裝置上讓遊戲要求 9 GiB，平均每影格約 19.6 毫秒，仍屬流暢可玩；提高到 10 GiB 時，平均約 29.8 毫秒，但常出現超過 33.3 毫秒的波動。後續也利用 Vulkan（跨平台圖形 API）的 `VK_EXT_pageable_device_local_memory` 擴充功能，讓程式標示各段記憶體的重要性，核心再依優先順序搭配 LRU（Least Recently Used，最久未使用）策略驅逐較不重要的資源。D3D12 遊戲可藉由 vkd3d-proton 將這些提示轉交 Vulkan；作者觀察到，在特定場景中，避免隨機驅逐資源可能帶來最高約 30% 的改善，但幅度高度依遊戲而定。相關成果已在 SteamOS 的 Stable 與 Preview 版本推出，完整上游整合仍需時間。
Hacker News 留言整體肯定文章兼具技術深度與可讀性，也讚賞 Linux 核心開發者願意投入這類底層效能問題。有人特別注意到 gpuvis 這類利用核心追蹤事件建立時間軸的工具，認為它能有效找出 GPU 工作時間到底耗在指令提交還是資料搬移。也有留言者指出，scanout 影像需要連續實體 VRAM 是問題核心，並追問是否能預留一小塊連續記憶體給顯示輸出，避免小型影像配置引發大規模驅逐。另有人關心這些機制是否同樣適用於大型語言模型（LLM）推論或其他運算工作負載，以及能否以 NVMe SSD 作為 GPU 記憶體交換空間；討論傾向認為，遊戲以外的工作負載有不同的資料存取模式與排程需求，不能直接視為相同解方，而應由應用程式提供更明確的記憶體使用提示。
👥 15 則討論、評論 💬
https://news.ycombinator.com/item?id=49342719