处理器x86/x86_64中是否使用物理或虚拟寻址在L1，L2和L3中缓存？

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

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

来源

2013-09-26 Alex

您无法寻址缓存。你只能处理内存。缓存由CPU私下处理。 –

@Kerrek SB是的我知道，但CPU缓存是否使用TLB和虚拟寻址的所有开销？ – Alex

你的问题的答案是 - 这取决于。这完全是一个CPU设计决策，它在性能和复杂性之间权衡。以最近的英特尔酷睿处理器为例 - 它们被物理标记并虚拟索引（至少根据http://www.realworldtech.com/sandy-bridge/7/）。这意味着高速缓存只能在纯物理地址空间中完成查找，以确定该行是否存在。然而，由于L1是32k，8路联合，这意味着它使用64组，所以你只需要地址位6到11以便找到正确的组。碰巧，虚拟地址和物理地址在这个范围内是相同的，因此您可以通过读取缓存集合来并行查找DTLB - 一种已知的技巧（请参阅 - http://en.wikipedia.org/wiki/CPU_cache以获得更好的解释）。

理论上，人们可以构建一个虚拟索引+虚拟标记的缓存，这将消除通过地址转换（TLB查找以及在TLB未命中情况下的页面散播）的要求。但是，这会造成很多问题，尤其是内存别名问题 - 两个虚拟地址映射到同一物理地址的情况。

说core1有虚拟地址缓存在这样一个完全虚拟的缓存中（它映射到phys addr C，但我们还没有完成这个检查）。 core2写入映射到同一个phys addr C的虚拟地址B - 这意味着我们需要一些机制（通常是由Jim Goodman创造的“snoop”），并使core1中的那条线无效，管理数据合并和一致性管理如果需要的话。但是，core1无法回答该snoop，因为它不知道虚拟地址B，也不会将物理地址C存储在虚拟高速缓存中。所以你可以看到我们有一个问题，虽然这主要与严格的x86系统相关，但是其他架构可能更加松懈，并且允许对这种缓存进行更简单的管理。

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

来源

2013-09-27 20:58:35 Leeor

非常感谢！在你看来，是否从x86机制的知识中获益？以及作为开发人员的我是否知道这一点，是否可以以某种方式优化我的程序的性能？ – Alex

当然，一个不知道他所运行的硬件的软件开发人员在优化它（如果需要的话）或调试它（需要时:)方面做得不好。缓存映射地址类型确实有点低，尽管它为一些重要的优化（如SW预取内在函数和缓存感知设计）打开了一扇门。看到这个伟大的职位的例子 - http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code。另外还有无序执行的问题，可能会提供一些提示，当然还有各种编译器优化（不是HW，但也很重要） – Leeor

我的意思是 - 从x86中的知识中受益：“它们是物理标记和虚拟索引“ – Alex

处理器x86/x86_64中是否使用物理或虚拟寻址在L1，L2和L3中缓存？

回答

相关问题