Linux 7.3 在显存用尽时提升性能
Linux 内核 7.3 引入了新的 VRAM 管理机制，在 GPU 显存耗尽时能显著提升性能，尤其适用于游戏和图形密集型工作负载。评论者将此与 Windows 和 macOS 在内存压力下的表现进行对比，讨论 overcommit、swap 和 OOM 杀进程，并指出如果不借助 earlyoom 或 systemd-oomd 等工具进行调优，Linux 往往仍会冻结或随机杀死应用。讨论串还强调了 Nvidia Linux 驱动长期存在的问题，以及 AMD 在 VRAM 与系统 RAM 之间更无缝回退的能力，并延伸到内存泄漏、桌面响应性，以及不同平台如何在稳定性与灵活性之间取舍的更广泛担忧。
对内核工作的总体反应
- 文章因清晰、细致的内核工程内容以及有用的跟踪工具（例如 gpuvis、DRM tracepoints）而受到赞赏。
- 许多人对 Linux 7.2/7.3 对游戏和 GPU 性能的关注表示兴奋。
- 一些人指出，良好的 VRAM 行为最终受限于硬件设计（例如 scanout 只能使用物理地址）。
游戏、VRAM 超量提交与资产浪费
- 大家对 VRAM 超量提交改进如何帮助拥有大量纹理、并且经常因过大或未使用资源而浪费 VRAM 的游戏非常感兴趣。
- 评论者提到现实中的例子：巨大的、完全没必要的纹理，以及发布时存在大量内存浪费的游戏。
- 有人想知道内核是否可以始终保留连续的 scanout 区域，或者通过移动页面并更新页表来在物理上“碎片整理” VRAM；其可行性仍不明确。
计算 / LLM 与 VRAM–磁盘设想
- 对于 LLM 推理，大多数人认为收益不大：工作负载更可预测，可以手动管理 GPU 内存。
- 讨论了将 GPU 数据转移到 NVMe 作为“VRAM swap”；最佳情况大约会慢 4 倍，因为受 PCIe 通道限制，所以只有小众场景才有可能。
Linux 与 Windows/macOS 的 GPU 和桌面体验
- 许多人为 Linux 内核的快速改进而欢呼；也有人指出回归问题（例如被回退的 GPU 调度器）以及发行版特定的破坏，尤其是在滚动发行版上。
- Windows 被认为在 HDR/VRR 和 eGPU 支持方面更成熟；Linux 被视为正在追赶，但并非在所有方面都更优。
- Apple Silicon/macOS 的评价褒贬不一：对一些人来说，OOM 界面和统一内存行为很好；但也有人报告在重度 ML/GPU 使用后持续出现变慢。
VRAM 处理：NVIDIA 对 AMD 以及 Wayland
- 多条报告称，Linux 上的 AMD GPU 在 VRAM 用满时会无缝溢出到系统 RAM，而 Linux+Wayland 下的 NVIDIA 历来会在 VRAM 耗尽时崩溃或拒绝分配。
- 还提到了 NVIDIA 驱动在 Wayland 上长期存在的 bug（例如与 KWin 的内存泄漏、缺少“shared VRAM”）；许多人得出结论：当前 AMD 是更安全的 Linux 选择，尤其适合 Wayland 和游戏。
OOM 行为、Swap 与调优
- 线程中有很大一部分讨论 Linux 在 RAM 压力下冻结，而 Windows/macOS 会变慢但仍保持响应。
- 解释主要围绕 Linux 的 overcommit 和启发式 OOM 杀进程，以及 Windows 更严格的分配模型。
- 提到的缓解措施包括：swap/zswap/zram、MGLRU 调优、earlyoom/systemd-oomd/nohang、overcommit 设置。
- 观点分歧很大：有人说“配置正确时 Linux 没问题”，也有人认为默认桌面 OOM 行为长期以来就是一个对用户不友好的问题。
杂项
- 澄清“VRAM”（而不是“vRAM”）才是标准用法；“vRAM”会让人联想到“virtual RAM”。
- 简短提到对低层性能工程中来自代表性不足群体的贡献表示赞赏。