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

Question

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

Ale*_*lex 27 x86 caching virtual-memory virtual-address-space tlb

处理器x86/x86_64中使用哪种寻址在L1,L2和L3(LLC)中进行缓存 - 物理或虚拟(使用PT/PTE和TLB)以及PAT(页面属性表)对它有何影响？

在这种情况下,驱动程序(内核空间)和应用程序(用户空间)之间是否存在差异？

简短回答 - 英特尔使用虚拟索引,物理标记(VIPT)L1缓存:线程之间的数据交换将用于在具有HT的一个Core上执行什么？

L1 - 虚拟寻址(在8-way用于定义的高速缓存中Set需要低12 bits,这在virt和phys中是相同的)
L2 - 物理寻址(需要访问Virt-2-Phys的TLB)
L3 - 物理寻址(需要访问Virt-2-Phys的TLB)

Answer 1

Lee*_*eor 37

你的问题的答案是 - 这取决于.这完全是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创造的术语),使core1中的那条线路无效,管理数据合并和一致性管理如果需要的话.但是,core1无法回答该监听,因为它不了解虚拟地址B,也不会将物理地址C存储在虚拟缓存中.所以你可以看到我们有一个问题,虽然这与严格的x86系统有关,但其他架构可能更宽松,并允许更简单地管理这些缓存.

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

当然,一个SW开发者不知道自己运行在会优化它(如果需要),或者调试它(需要:)时做的不好硬件.高速缓存映射地址类型是有点低的水平的确,虽然它打开舱门到一些重要的optimiations如SW预取内在和缓存意识的设计).有关示例,请参阅这篇精彩文章 - http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code.还有无序执行的问题可能提供一些提示,当然还有各种编译器优化(不是硬件,但也很重要) (2认同)
它不是x86,它只是许多CPU上常见的设计点.我很确定大多数基于ARM的设计也在使用它.为了从中受益,您需要确保您的地址在标签位上没有过多的物理对齐(或者至少具有良好的传播) - 这并不是一件容易的事,因为您通常不会决定操作系统分配页面的位置. (2认同)
不多,可能没什么.高速缓存旨在实现地址的最佳传播,以最大限度地减少高速缓存抖动.通过平铺大型结构以适应它或避免错误共享来设计代码以便缓存友好,而不是担心物理页面被分散,这将有更大的好处.我**会注意低位如何匹配(例如,当使用A和B阵列时,尝试将它们放在不同的页面偏移处),但这适用于虚拟地址而不是与VIPT缓存特别相关 (2认同)
re:VIPT L1速度hack,允许从TLB访问并行获取集合中的标记(和数据).它实际上更像是PIPT缓存,索引转换是免费的(因为索引位都低于页面偏移量).我刚刚写了一篇文章[详细解释它的工作原理](http://stackoverflow.com/a/38549736/224132).您可能想要链接它以及维基百科. (2认同)

归档时间：	12 年前
查看次数：	9584 次
最近记录：	7 年，6 月前