本文探讨了显存超限使用的问题，指出理论上显存不足应仅影响性能而非稳定性，并介绍了通过内核补丁改进显存管理、减少超限带来的负面影响的方法。

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的内容（如个人经历、代码细节、脚注等）。

标题：VRAM管理（下）：突破物理显存的限制

核心问题：当游戏所需显存超过物理容量时，会发生什么？

通常认为，一旦显存溢出，游戏体验将彻底崩溃：性能骤降至无法游玩，甚至频繁崩溃。但本文探讨了如何将这种负面影响降到最低。

理论上的可能性

理论上，显存溢出应仅导致性能问题，而非稳定性问题。当显存被超额分配时，部分数据会被迫从高速的GPU显存迁移到较慢的CPU内存。GPU访问CPU内存需通过PCIe总线，其带宽远低于显存。例如，在PCIe 4.0 x16连接下，要维持30帧/秒的帧率，每帧从被迁移的内存中读取的数据量不能超过约1GiB。这是性能下降的根本原因。

并非所有内存都“平等”

性能影响并非绝对。关键在于数据的访问模式。

1. 缓存的作用：如果被迁移的数据能被GPU缓存命中，那么访问延迟的差异会大大缩小。例如，对于能完全放入L2缓存的小数据块，无论其物理位置在显存还是CPU内存，访问延迟几乎相同。
2. 访问频率与模式：如果被迁移的内存访问模式对缓存友好，或者访问频率极低（例如，只读取一小部分），那么性能损失会小得多。因此，预测实际性能表现非常复杂，取决于被迁移数据的具体使用方式。

现实中的挑战：稳定性问题

在实践中，显存溢出首先会引发稳定性问题，例如内核返回“内存不足”错误，导致命令提交失败。这源于内核驱动在处理显存竞争时的死锁问题。

当多个进程（如游戏和系统界面）同时争夺显存时，一个进程在提交GPU命令时需要锁定其使用的所有内存。如果此时另一个进程也需要锁定这些内存以进行数据迁移，就可能发生死锁。内核虽有死锁检测机制，但在图形子系统的内存管理层（TTM）中，该机制并未完全实现，导致在内存压力下，内核会直接放弃提交，而不是重试。作者通过修复相关代码，解决了这个稳定性问题。

性能瓶颈：内存“乒乓”效应

解决了崩溃问题后，性能依然糟糕。通过性能分析工具发现，GPU大部分时间并未用于渲染，而是在进行内存迁移。问题在于，两个竞争进程会不断将同一块内存从显存中踢出，又立即移回，形成“乒乓”效应，导致性能灾难。

罪魁祸首：显示扫描输出缓冲区

这种“乒乓”效应的一个主要诱因是用于屏幕显示的扫描输出缓冲区。这类缓冲区有特殊要求：它必须位于显存中，并且物理内存必须是连续的。当显存碎片化严重时，为了给一个很小的扫描输出缓冲区腾出连续的物理空间，内核可能需要驱逐大量（甚至数GiB）的其他显存数据，造成巨大的性能开销。

解决方案：启发式算法与优先级

1. 启发式节流：作者设计了一套启发式算法。当检测到应用的内存被驱逐后，内核会先进入“硬节流”阶段，短时间内完全不尝试将内存移回显存。随后进入“软节流”阶段，缓慢恢复，但避免驱逐其他应用的内存。这有效防止了“乒乓”效应，并在稳定性和恢复速度间取得了平衡。

2. 利用应用优先级：Vulkan API提供了VK_EXT_pageable_device_local_memory扩展，允许应用为不同的显存分配设置优先级。内核可以利用这个信息，在需要驱逐内存时，优先驱逐低优先级的数据。作者在内核的LRU（最近最少使用）列表中集成了优先级排序，确保高优先级数据（如游戏核心资源）最后被驱逐。

实际效果与结论

通过上述优化，即使游戏请求的显存超过物理容量（例如，在8GiB显存上请求9GiB），性能依然可以保持可玩水平。虽然当超额量过大（如请求10GiB）时，帧率波动会变得明显，但整体体验已大幅改善。

总结： 显存溢出并非世界末日。通过内核驱动的优化（解决死锁、引入启发式算法）和应用层的配合（提供内存优先级提示），可以显著缓解其带来的性能冲击。即使部分数据被迁移到系统内存，性能下降也可能是可控的。这些改进已集成到SteamOS中，并正在向上游Linux内核提交。

根据评论内容，总结主要观点如下：

1. 文章质量与学习价值（高度认可） - 评论1："Well written and very informative. I am glad we have these enthusiastic people around for Linux kernel development!" - 评论2："This is a nice blog and it makes sense to me now... I've previously had to do tweaks and go-arounds without really understanding what was going on behind the scenes."

2. 技术细节与改进方向（专业讨论） - 评论3指出显示硬件绕过GPU虚拟内存架构直接使用物理地址的问题："Only so smart your memory management can be when you have to pay the cost of doing it manually." - 评论5建议LRU优先级管理VRAM，并探讨VRAM到NVMe直接交换的可行性："I guess an LRU with priority would handle VRAM for games pretty decently... What about VRAM to Disk specifically NVME?"

3. 应用场景关注（平衡观点） - 评论4询问对计算负载（如LLM推理）的影响："What does this mean for compute workloads? Specifically, LLM inference. Does it mean anything at all, or is this purely a games-thing?" - 评论5补充对大规模计算负载性能的疑问："i wonder how the performance would be on compute workloads running with NVME as a swap for GPU VRAM."

4. 对比Windows更新体验（正面评价） - 评论6对比Linux与Windows更新体验："Meanwhile in the Windows world, users hate updates... I genuinely can't think of a single instance that made users exclaim, 'oh boy I just can't wait for the next Patch Tuesday!'"

5. 内核设计哲学（深度思考） - 评论7支持作者观点，认为应用程序比内核更了解内存粘性需求："when allocating memory ultimately the application itself is in the best position to inform the kernel about the desired stickiness to VRAM. The best a kernel can do is guessing." - 评论7还注意到年轻跨性别者在底层性能工程中的贡献："it strikes me how much we owe to young trans people for low level performance engineering."