现代 CPU 中的 Cache 结构 - 版本历史

Comcat：/* 摘要 */

2014-04-30T04:33:38Z

‎摘要

Comcat：/* 乱弹 */

2014-04-30T04:33:31Z

‎乱弹

Comcat：/* 组相联工作方式 */

2014-04-30T04:33:11Z

‎组相联工作方式

Comcat：/* 相联方式 */

2014-04-30T04:32:20Z

‎相联方式

Comcat：/* 组相联 == */

2014-04-30T04:32:09Z

‎组相联 ==

Comcat：/* 组相联 == */

2014-04-30T04:31:44Z

‎组相联 ==

Comcat：/* Cache 行 */

2014-04-30T04:30:51Z

‎Cache 行

Comcat：/* 组相联工作方式 */

2014-04-30T04:30:09Z

‎组相联工作方式

Comcat：/* 相联方式 */

2014-04-30T04:28:33Z

‎相联方式

Comcat：/* 组相联 == */

2014-04-30T04:28:16Z

‎组相联 ==

←上一版本		2014年4月30日 (三) 04:33的版本
第148行：		第148行：

	Way_Size ＝ Cache_Size / Ways		Way_Size ＝ Cache_Size / Ways
		+

	当 log2(Way_Size) > log2(PAGE_SIZE) 时，系统具有“颜色位”，其影响为：		当 log2(Way_Size) > log2(PAGE_SIZE) 时，系统具有“颜色位”，其影响为：

@@ 第119行： / 第119行： @@
 在 OS 层面上，我们还有分页的概念，物理内存被分为若干个 Page Frame，其大小以 4KB 始。对 4KB 页大小的系统，其地址的低 12 位被用来索引页内数据
 若系统采用 4KB 的 PAGE_SIZE，则第一个 Page Frame 总是会被索引到 cache 的前 256 组，第二个 Page Frame会被索引到 cache 的后 256 组，第三个又会到 cache 的前 256 组。。。。。。（给在前 256 的涂红色，给后 256
 的涂黑色） 倘若系统在分别 PF 的时候，大多数的都跑到前 256 组去了，那就杯具了。在频繁换页的系统中，Cache的路数总是一定，用完了组内的行，系统就会复用一些行，原来的数据也就被替换，再访问时，就是 cache miss，性能就下来。那如何让系统在 “OS层面上物理页面（Page）的分配能够比较均匀的落在CPU层面上的SET中“？
 通俗地说，就是让 OS 在分配页面的时候，让红色的页和黑色的页一样多。这个应该就是 Page Coloring
 用颜色位更形式化地说：
 作为一个理解的便利，请各位看官看看地址的组索引位和行内索引位所表示的空间大小是多少？ 2^13 ＝ 8KB，这个值正是 Cache 一路 (Way Array)的大小： 32KB/4 = 8KB (Way_Size)
 因此拿到一个 Cache 在判断系统的 Color 位时，可以借助一个 Way Array 的概念，一路 Cache 的大小就是地址用来索引的低位空间，相当于用地址的低位访问 Cache 的一路内部存储
 当 Way_Size > PAGE_SIZE 时，即 log2(Way_Size) > log2(PAGE_SIZE)， 则用于索引一路 Cache 的地址低位较用于页内偏移的低位多了 log2(Way_Size) – log2(PAGE_SIZE)，为了分析的方便，往往将这个多出的位称为颜色位
 (color bit)。对于上述的 Cache，若系统采用 4KB 的 PAGE_SIZE，则Addr[12] 即为颜色位。则 OS 在分配页时，保证每种颜色的页一样多即可。如：Addr[13:12] 为颜色位的情形，00, 01, 10, 11 一样多即可。
 若 log2(Way_Size) <= log2(PAGE_SIZE)，则数据可以很均衡地进入 Cache 没有谈论的必要的，但可以作为另外一个思路，即：提高系统的 Page Size

←上一版本		2014年4月30日 (三) 04:33的版本
第109行：		第109行：

	VA 索引，PA 匹配 Cache 之工作方式图：		VA 索引，PA 匹配 Cache 之工作方式图：
		+
		+
		+	[[文件:Vipt.match.png]]

@@ 第48行： / 第48行： @@
 === 相联方式 ===
-==== 组相联 ======
+==== 组相联 ====
 通俗地讲就是 Cache 行的分组，比如 4 路组相联，就是 4 行一组，4 行一组。。。。。。

←上一版本		2014年4月30日 (三) 04:32的版本
第60行：		第60行：

	[[文件:Cache.way .set .png]]		[[文件:Cache.way .set .png]]
−
−
−	~~[[文件:C2.png]]~~


第71行：		第68行：

	Cache 组号 = 内存行号 % Cache 总组数		Cache 组号 = 内存行号 % Cache 总组数
		+
		+
		+
		+	[[文件:C2.png]]
		+

←上一版本		2014年4月30日 (三) 04:31的版本
第61行：		第61行：
	[[文件:Cache.way .set .png]]		[[文件:Cache.way .set .png]]

		+
		+	[[文件:C2.png]]

←上一版本		2014年4月30日 (三) 04:30的版本
第30行：		第30行：


−	[[文件:~~Addr~~.~~split~~ .png]]	+	[[文件:Cache.line .png]]

@@ 第93行： / 第93行： @@
 K 路组相联 Cache 的通常工作方式是：先用物理地址或虚拟地址索引组，然后用物理地址 (PA) 或虚拟地址 (VA) 同时与组内K 行之 Tag 域同时匹配，有匹配则为命中 (Hit)，尔后将命中的行中相应的字传给 Register。
 以上述 32KB ，4 路组相联，行大小为 16Bytes 的 Cache 为例，正常工作时其对地址的划分如下所示：
 Addr[12:4] 用来索引组，9 bit 可索引 512 组Addr[3:0] 用来行内索引字节，2^4 = 16 Bytes
 VA 索引，PA 匹配 Cache 之工作方式图：

@@ 第51行： / 第51行： @@
 通俗地讲就是 Cache 行的分组，比如 4 路组相联，就是 4 行一组，4 行一组。。。。。。
 比如 32KB 的 4 路组相联 Cache，行大小为 16Bytes 的话，他就有 32*1024/(16 * 4)= 512 组
 CPU 访问组相联 Cache 时，就先用地址索引到组，然后组内同时匹配 Tag，进行路选。一个典型的组相联 Cache 如下：
 [[文件:Cache.way .set .png]]
@@ 第61行： / 第64行： @@
 内存逻辑上也按 Cache 行大小分块，按地址由低向高，依次编号。因此 Cache 与内存就会有个映射问题，如：第四个内存行中的数据被CPU访问时，该行将缓存于 Cache 中的哪一行？
 组相联的 Cache 是先索引组，其规则为：
    Cache 组号 = 内存行号 % Cache 总组数
 对于上图这个只有 2 个组的 Cache，假设其行大小为 16Bytes，这个组索引的过程，实际上就是用地址的第 5 位(ADDR[4]) 索引的过程，0 就在第一组，1 就在第二组。地址的低 4 位用于行内索引数据 (ADDR[3:0])
 尔后，内存行可以映射到该组内的任意行上。缓存数据时，有空占空，如组内所有行被占用，则使用替换算法(LRU, Random, FIFO, LFU)替换掉一行。

←上一版本		2014年4月30日 (三) 04:28的版本
第55行：		第55行：

	CPU 访问组相联 Cache 时，就先用地址索引到组，然后组内同时匹配 Tag，进行路选。一个典型的组相联 Cache 如下：		CPU 访问组相联 Cache 时，就先用地址索引到组，然后组内同时匹配 Tag，进行路选。一个典型的组相联 Cache 如下：
		+
		+	[[文件:Cache.way .set .png]]
		+