物理或虚拟寻址在处理器 x86/x86_64 中用于在 L1、L2 和 L3 中进行缓存？答案

【问题标题】：Physical or virtual addressing is used in processors x86/x86_64 for caching in the L1, L2 and L3?物理或虚拟寻址在处理器 x86/x86_64 中用于在 L1、L2 和 L3 中进行缓存？
【发布时间】：2013-10-03 01:45:36
【问题描述】：

x86/x86_64 处理器中使用哪种寻址方式在 L1、L2 和 L3(LLC) 中进行缓存 - 物理或虚拟（使用 PT/PTE 和 TLB），PAT(page attribute table) 会以某种方式对其产生影响？

在这种情况下，驱动程序（内核空间）和应用程序（用户空间）之间有区别吗？

简答 - 英特尔使用 虚拟索引、物理标记 (VIPT) L1 缓存：What will be used for data exchange between threads are executing on one Core with HT?

L1 - 虚拟寻址（在 8-way 缓存中定义 Set 需要低 12 bits 这在 virt 和 phys 中相同）
L2 - 物理寻址（需要访问 TLB 以获得 Virt-2-Phys）
L3 - 物理寻址（需要访问 TLB 以获得 Virt-2-Phys）

【问题讨论】：

您无法寻址缓存。您只能寻址内存。缓存由 CPU 私下处理。
@Kerrek SB 是的，我知道，但是 CPU 缓存是否使用 TLB 和虚拟寻址的所有开销？
L1 仍然是物理标记的，正如您所说，索引获得了虚拟的速度，但也没有物理的别名。所以它真的是L1 - 物理；它的行为与 PIPT 完全相同，但延迟时间降低了几个周期。在 Intel CPU 中只有 uop-cache 是虚拟寻址的。请不要在您的问题中编辑答案。

标签： caching x86 virtual-memory tlb virtual-address-space

【解决方案1】：

您的问题的答案是 - 视情况而定。这完全是一个 CPU 设计决策，需要在性能和复杂性之间进行权衡。

以最新的 Intel Core 处理器为例 - 它们带有物理标记和虚拟索引（至少根据 http://www.realworldtech.com/sandy-bridge/7/）。这意味着缓存只能在纯物理地址空间中完成查找，以确定该行是否存在。但是，由于 L1 是 32k，8 路关联，这意味着它使用 64 个集合，因此您只需要地址位 6 到 11 即可找到正确的集合。碰巧的是，虚拟地址和物理地址在此范围内是相同的，因此您可以在读取缓存集的同时查找 DTLB - 这是一个已知技巧（请参阅 - http://en.wikipedia.org/wiki/CPU_cache 以获得良好的解释）。

理论上可以构建一个虚拟索引 + 虚拟标记缓存，这将消除通过地址转换的要求（TLB 查找，以及在 TLB 未命中的情况下进行页面遍历）。但是，这会导致许多问题，尤其是内存别名问题——即两个虚拟地址映射到同一个物理地址的情况。

假设 core1 在这样一个完全虚拟的缓存中具有虚拟地址 A 缓存（它映射到 phys 地址 C，但我们还没有进行此检查）。 core2 写入映射到相同物理地址 C 的虚拟地址 B - 这意味着我们需要一些机制（通常是“窥探”，由 Jim Goodman 创造的术语）去使 core1 中的该行无效，管理数据合并和一致性管理如果需要的话。但是，core1 无法响应该窥探，因为它不知道虚拟地址 B，并且不将物理地址 C 存储在虚拟缓存中。所以你可以看到我们有一个问题，虽然这主要与严格的 x86 系统相关，但其他架构可能更宽松，并且允许更简单地管理此类缓存。

关于其他问题 - 我能想到的与 PAT 没有真正的联系，缓存已经设计好了，不能针对不同的内存类型进行更改。另一个问题的答案相同 - 硬件主要位于用户/内核模式之间的区别之下（除了它提供的安全检查机制，主要是各种环）。

【讨论】：

非常感谢！在您看来，了解 x86 上的机制有什么好处吗？作为开发人员，我是否可以通过某种方式优化程序的性能？
当然，一个不知道他运行的硬件的软件开发人员在优化它（如果需要的话）或调试它（如果需要时:) 方面做得很差。缓存映射地址类型确实有点低级，尽管它确实为一些重要的优化打开了一个孵化器，例如 SW 预取内在函数和缓存感知设计）。有关示例，请参见这篇很棒的帖子 - stackoverflow.com/questions/16699247/…。还有乱序执行的问题可能会给出一些提示，当然还有各种编译器优化（不是硬件，但也很重要）
它不是 x86，它只是一个常见的设计点，出现在许多 CPU 上。我很确定大多数基于 ARM 的设计也在使用它。要从中受益，您需要确保您的地址在标签位上没有过多地物理对齐（或者至少具有良好的分布）——这并非易事，因为您通常不会决定操作系统将页面分配到何处。
不多，可能没什么。缓存旨在实现地址的最佳分布，以最大程度地减少缓存抖动。通过平铺大型结构以适应它或避免错误共享，将您的代码设计为通常对缓存友好，这比担心物理页面分散的好处要大得多。我会注意低位如何匹配（例如，在使用 A 和 B 数组时，尝试让它们位于不同的页面偏移量），但这适用于虚拟地址，与 VIPT 无关缓存
re：VIPT L1 speed hack，它允许从一个集合中获取标签（和数据）与 TLB 访问并行。它实际上更像是一个 PIPT 缓存，索引转换是免费发生的（因为索引位都低于页面偏移量）。不久前我尝试写a detailed explanation of why it works。您可能想链接它以及维基百科。