当对页面使用直写缓存策略时

When use write-through cache policy for pages

我正在阅读 MDS 攻击论文 RIDL: Rogue In-Flight Data Load。将pages设置为write-back、write-through、write-combined或uncacheable,通过不同的实验确定Line Fill Buffer是微架构泄露的原因。


切线:我知道内存可能是不可缓存的,但我假设可缓存数据总是缓存在回写缓存中,即我假设 L1、L2 和 LLC 总是回写缓存.

我在 Computer Architecture book 中阅读了回写缓存​​和直写缓存之间的区别。它说:

Write-through caches are simpler to implement and can use a write buffer that works independently of the cache to update memory. Furthermore, read misses are less expensive because they do not trigger a memory write. On the other hand, write-back caches result in fewer transfers, which allows more bandwidth to memory for I/O devices that perform DMA. Further, reducing the number of transfers becomes increasingly important as we move down the hierarchy and the transfer times increase. In general, caches further down the hierarchy are more likely to use write-back than write-through.

因此,直写缓存更易于实现。我可以看到这是一个优势。但是,如果缓存策略由页面 table 属性设置 table 那么就不会有实现优势 - 每个缓存都需要能够以回写或直写的方式工作。

问题

  1. 是否每个缓存(L1、L2、LLC)都可以在回写或直写模式下工作?那么如果页面属性设置为write-through,那么它们都是write-through?
  2. Write combining对GPU显存很有用;访问硬件寄存器时,Uncacheable 很好。什么时候应该将页面设置为直写?这样做有什么好处?
  3. 是否有任何直写缓存(如果它确实是硬件的 属性 而不仅仅是由 pagetable 属性控制的东西)或者是所有缓存的趋势是否创建为回写以减少流量?

Can every cache (L1, L2, LLC) work in either write-back or write-through mode?

在大多数 x86 微体系结构中,是的,所有数据/统一缓存都是(能够)回写并在该模式下用于所有普通 DRAM。 有一些细节和链接。除非另有说明,否则任何谈论 x86 的人都默认假设 DRAM 页面将是 WB。

AMD Bulldozer 做出了非常规的选择,使用直写 L1d,在它和 L2 之间有一个小的 4k 写入组合缓冲区。https://www.realworldtech.com/bulldozer/8/). This has many disadvantages and is I think widely regarded (in hindsight) as one of several weaknesses or even design mistakes of Bulldozer-family (which AMD fixed for Zen). Note also that Bulldozer was an experiment in CMT instead of SMT (two weak integer cores sharing an FPU/SIMD unit, each with separate L1d caches sharing an L2 cache) https://www.realworldtech.com/bulldozer/3/ 显示了系统架构.

当然 Bulldozer L2 和 L3 缓存仍然是 WB,架构师并没有疯。 WB 缓存对于减少共享 LLC 和内存的带宽需求至关重要。甚至直写式 L1d 也需要一个写组合缓冲区,以允许 L2 缓存更大更慢,从而达到有时在 L1d 未命中时命中的目的。另见 Why is the size of L1 cache smaller than that of the L2 cache in most of the processors?

直写式缓存可以简化设计(尤其是单核系统),但通常 CPUs 在几十年前就超越了这一点。 (Write-back vs Write-Through caching?)。 IIRC,一些非 CPU 工作负载有时会受益于直写缓存,尤其是在没有写入分配的情况下,因此写入不会污染缓存。 x86 有 NT 存储来避免这个问题。

So if the page attribute is set to write-through, then they all will be write-through?

是的,每个商店都必须在标记为 WT 的页面中一直转到 DRAM。

缓存针对 WB 进行了优化,因为这是每个人都在使用的,但希望确实支持将线路传递到外部缓存而不从 L1d 逐出。 (所以 WT 不会 必须 将存储变成类似 movntps 缓存绕过/驱逐存储的东西。但是检查一下;显然在某些 CPU 上,比如至少 Pentium Pro 系列,L1 中的 WT 存储命中更新行,但 L2 中的 WT 命中驱逐行而不是将其引入 L1d。)

When should a page be set to write-through? What are the advantages to that?

基本没有; (几乎?)所有 CPU 工作负载在 WB 内存下表现最佳。

操作系统甚至懒得让用户 space 轻松(或可能?)分配 WC 或 WT DRAM 页面。 (尽管这当然不能证明它们 永远不会 有用。)例如关于 , I found a link 关于一个 Linux 补丁,该补丁从未进入主线内核,增加了映射页面 WT 的可能性。

WB、WC 和 UC 分别适用于普通 DRAM、设备内存(尤其是 GPU)和 MMIO。

我至少看过一篇针对某些工作负载对 WT、WB、UC 和 WC 进行基准测试的论文(谷歌搜索但没有找到,抱歉)。人们测试晦涩的 x86 东西有时会为了完整性而包括它。例如The Microarchitecture Behind Meltdown 总的来说是一篇好文章(并且与您正在阅读的内容相关)。

WT 的少数优点之一是存储会立即进入 L3,来自其他内核的负载可能会受到影响。这可能值得每个存储的额外成本那个页面,特别是如果你小心地将你的写入合并到一个大的 32 字节 AVX 存储中。 (或 64 字节 AVX512 全行写入。)当然只将该页用于共享数据。

不过,我还没有看到有人推荐这样做,而且我也没有尝试过。可能是因为通过 L3 写入的额外 DRAM 带宽对于大多数用例来说都不值得受益。但也可能是因为您可能必须编写内核模块才能以这种方式映射页面。

如果 CPUs 在 WT 存储的 L2 或 L3 命中时从外部缓存中逐出,它甚至可能无法以这种方式工作,就像@Lewis 评论说 PPro 被记录在案要做。

所以也许我对 WT 的目的有误,它是为(或至少可用的)设备内存用例设计的,比如 GPU 不会修改的部分视频 RAM。