PIPT L1 缓存的最小关联性也是 VIPT,无需将索引转换为物理即可访问集合

cne*_*tt1 4 caching cpu-architecture virtual-memory cpu-cache

这个问题是在本科计算机体系结构课程中有关虚拟内存的部分中提出的。助教和教授都无法充分回答这个问题,而且网上资源也有限。

问题:

假设处理器具有以下规格:

  • 8KB页面
  • 32位虚拟地址
  • 28位物理地址
  • 二级页表,第一级页表1KB,第二级页表8KB
  • 4字节页表条目
  • 16 项 8 路组关联 TLB
  • 除了物理帧(页)号之外,页表条目还包含有效位、可读位、可写位、可执行位和仅内核位。

现在假设该处理器有一个 32KB L1 缓存,其标签是根据物理地址计算的。在计算与虚拟地址相对应的物理地址之前,缓存必须具有允许访问适当的缓存集的最小关联性是多少?

直觉:

我的直觉是,如果缓存中的索引数量和虚拟页面(也称为页表条目)数量可以被彼此整除,那么我们可以直接从缓存中检索物理页面中包含的字节,而无需计算物理页,从而提供小的加速。但是,我不确定这是否是正确的直觉,并且绝对不知道如何遵循它。有人可以解释一下吗?

注意:我计算出页表条目的数量为 2^19,如果这对任何人有帮助的话。

Pet*_*des 5

在计算与虚拟地址相对应的物理地址之前,缓存必须具有允许访问适当的缓存集的最小关联性是多少?

他们只指定缓存是物理标记的

始终可以构建虚拟索引缓存,没有最小关联性。即使是直接映射(每组 1 路)也可以。有关 VIPT 与 PIPT(以及 VIVT,甚至不常见的 PIVT)的详细信息,请参阅缓存寻址方法混淆。

为了这个问题不是微不足道的,我认为他们也意味着“不会产生别名问题”,因此 VIPT 只是 PIPT(物理索引、物理标记)的加速。您可以获得允许 TLB 查找与索引集方式获取标签(和数据)并行的好处,而没有任何缺点。

我的直觉是,如果缓存中的索引数量和虚拟页面(也称为页表条目)数量可以被彼此整除,那么我们可以直接从缓存中检索物理页面中包含的字节,而无需计算物理页

您需要物理地址来检查标签;请记住您的缓存已被物理标记。(虚拟标记缓存确实存在,但通常必须在上下文切换到具有不同页表 = 不同虚拟地址空间的进程时刷新。这过去用于旧 CPU 上的小型 L1 缓存。)

通常假设两个数字都是 2 的幂,因此它们总是可以被整除。

页面大小始终是 2 的幂,因此您只需采用地址中不同的位范围即可将地址拆分为页号和页内偏移量。

小/快速缓存大小也始终具有 2 组数的幂,因此索引“函数”只是从地址中获取一系列位。对于虚拟索引缓存:来自虚拟地址。对于物理索引缓存:来自物理地址。(像大型共享 L3 缓存这样的外部缓存可能具有更高级的索引功能,例如更多地址位的散列,以避免地址彼此偏移 2 的大幂时出现别名。)

缓存大小可能不是 2 的幂,但您可以通过非 2 的幂关联性(例如 10 或 12 路并不罕见)而不是非 2 的幂行大小来实现这一点或套数。对一个集合建立索引后,缓存会获取该集合所有路的标签并并行比较它们。(对于快速 L1 缓存,通常也并行获取由行偏移位选择的数据,然后比较器只是将该数据复用到输出中,或者引发不匹配的标志。)


无别名的 VIPT 要求(如 PIPT)

对于这种情况,您需要所有索引位都来自页面偏移量下方。它们将“免费”从虚拟转换为物理,因此 VIPT 缓存(在 TLB 查找之前索引一组)不存在同义/同义问题。除了性能之外,还有 PIPT。

我详细回答了为什么大多数处理器中 L1 缓存的大小小于 L2 缓存的大小?包括有关速度黑客的部分。

虚拟索引物理标记缓存同义词显示了缓存具有该属性的情况,并且需要操作系统进行页面着色以避免同义词问题。

如何计算集关联缓存中标签、索引和偏移量的缓存位宽度,TLB有一些关于缓存大小/关联性的更多注释,以提供该属性。

公式:

  • 最小关联性 = 缓存大小 / 页大小

例如,具有 8kiB 页的系统需要 32kiB L1 缓存至少为 4 路关联,以便索引位仅来自低 13。

直接映射缓存(每组 1 路)只能有 1 页那么大:行内字节和索引位总计最多为页内字节偏移量。直接映射(单向)缓存中的每个字节都必须具有唯一的索引:偏移地址,并且这些位来自完整地址的连续低位。

换句话说,2^(idx_bits + within_line_bits)就是每组只有一个路的缓存总大小。2^N 是页大小,页偏移量为 N(免费转换的页内字节地址位的数量)。

实际的组数(在本例中=行)取决于行大小和页面大小。使用更小/更大的行只会改变偏移量和索引位之间的划分。

从那里开始,在不从更高地址位进行索引的情况下使缓存更大的唯一方法是为每组添加更多路,而不是更多路。