CPU Cache汇总

1、什么是cache,为什么需要cache?

        如果CPU需要将一个变量加1，地址为A，一般的操作分为3步：

①、CPU从内存中读取地址A的内容到内部通用寄存器x0；

②、通用寄存器x0+1；

③、CUP将寄存器中的内容写入主存；

        在实际中，CPU寄存器和主存之间存在很大的差异，CPU register的速度一般小于1ns，主存的速度一般是65ns左右，速度差异百倍，在硬件设计上，我们将cache放置在CPU和主存之间，作为主存数据的缓存，当CPU试图从主存中load/store数据时，CPU会首先从cache中查找对应的数据是否缓存在chche中，速度会得到极大提升。

         cache的主要理论基础是局部性原理，程序局部性分为时间局部性和空间局部性。时间局部性是指被CPU访问的数据，短期内还要被继续访问，比如循环、递归、方法的反复调用等。空间局部性是指被CPU访问的数据相邻的数据，CPU短期内还要被继续访问，比如顺序执行的代码、连续创建的两个对象、数组等。

        一个存储器层次大体结构如图所示，速度越快的存储设备自然价格也就越高，随着数据访问量的增大，单纯的增加一级缓存的成本太高，性价比太低，所以才有了二级缓存和三级缓存，他们的容量越来越大，速度越来越慢（但还是比内存的速度快），成本越来越低 

        在Cortex-A53架构上，L1 cache分为单独的instruction cache（ICache）和data cache（DCache）。L1 cache是CPU私有的，每个CPU都有一个L1 cache。一个cluster 内的所有CPU共享一个L2 cache，L2 cache不区分指令和数据，都可以缓存。所有cluster之间共享L3 cache。L3 cache通过总线和主存相连。

2、什么是cache line？多级cache之间的配合？

（1）cache line

        cache Line可以理解为CPU cache中的最小缓存单位。Main Memory-cache或cache-cache之间的数据传输不是以字节为最小单位，而是以cache Line为最小单位，称为缓存行。

        目前主流的cache Line大小都是64字节，假设有一个64K字节的cache，那这个cache所能存放的cache Line的个数就是1K个。

旁注：

很容易混淆高速缓存行、组和块之间的区别 。 让我们来回顾一下这些概念，确保概念清晰：
• 块是一个固定大小的信息包，在高速缓存和主存（或下一层高速缓存）之间来回传送 。
• 行是高速缓存中的一个容器，存储块以及其他信息 （ 例如有效位和标记位） 。
• 组是一个或多个行的集合 。 直接映射高速缓存中的组只由一行组成 。 组相联和全相联高速缓存中的组是由多个行组成的 。
在直接映射高速缓存中，组和行实际上是等价的 。不过，在相连高速缓存中，组和行是很不一样的，这两个词不能互换使用。
因为一行总是存储一个块，术语“行”和“块“通常互换使用。例如，系统专家总是说高速缓存的“行大小＂，实际上他们指的是块大小 。 这样的用法十分普遍 ， 只要你理解块和行之间的区别，它不会造成任何误会。
 

（2）多级cache之间的配合

• inclusive cache(某一地址的数据可能存在多级缓存中) 当CPU试图从某地址load数据时，首先从L1 cache中查询是否命中，如果命中则把数据返回给CPU 如果L1 cache缺失，则继续从L2 cache中查找。当L2 cache命中时，数据会返回给L1 cache以及CPU 如果L2 cache也缺失，很不幸，我们需要从主存中load数据，将数据返回给L2 cache、L1 cache及CPU

• exclusive cache 这种cache保证某一地址的数据缓存只会存在于多级cache其中一级

3、cache的分配策略和写入策略（更新策略）？

（1）cache的分配策略

         cache的分配策略是指我们什么情况下应该为数据分配cache line，cache分配策略分为读和写两种情况:

读分配(read allocation) ：当CPU读数据时，发生cache缺失，这种情况下都会分配一个cache line缓存从主存读取的数据。默认情况下，cache都支持读分配。

写分配(write allocation) ：当CPU写数据发生cache缺失时，才会考虑写分配策略。当我们不支持写分配的情况下，写指令只会更新主存数据，然后就结束了。当支持写分配的时候，我们首先从主存中加载数据到cache line中（相当于先做个读分配动作），然后会更新cache line中的数据。

（2）cache的写入策略

        cache的写入策略有两种，分别是WriteThrough（直写模式）和WriteBack（回写模式）:

直写模式：在数据更新时，将数据同时写入内存和cache，该策略操作简单，但是因为每次都要写入内存，速度较慢。

回写模式：在数据更新时，只将数据写入到cache中，只有在数据被替换出cache时，被修改的数据才会被写入到内存中，该策略因为不需要写入到内存中，所以速度较快。但数据仅写在了Cache中，Cache数据和内存数据不一致，此时如果有其它CPU访问数据，就会读到脏数据，出现bug，所以这里需要用到Cache的一致性协议来保证CPU读到的是最新的数据。     

4、cache之间的映射方式？ 

        组相连映射实际上是直接映射和全相连映射的一种折中方案，其中直接映射可以理解为组的行数只有一行，全相连映射可以理解为只有一个组，包括了所有的行，其中主存一个分区的块数等于cache组数。

（1）直接映射 

         直接映射如图所示，每个主存块只能映射Cache的一个特定块。直接映射是最简单的地址映射方式，它的硬件简单，成本低，地址转换速度快，但是这种方式不太灵活，Cache的存储空间得不到充分利用，每个主存块在Cache中只有一个固定位置可存放，容易产生冲突，使Cache效率下降，因此只适合大容量Cache采用。

        例如，如果一个程序需要重复引用主存中第0块与第16块，最好将主存第0块与第16块同时复制到Cache中，但由于它们都只能复制到Cache的第0块中去，即使Cache中别的存储空间空着也不能占用，因此这两个块会不断地交替装入Cache中，导致命中率降低。 

        直接映射方式下主存地址格式如图，主存地址为s+w位，Cache空间有2的r次方行，每行大小有2的w次方字节，则Cache地址有w+r位。通过Line确定该内存块应该在Cache中的位置，确定位置后比较标记是否相同，如果相同则表示Cache命中，从Cache中读取。

（2）组相连映射

        直接映射高速缓存中冲突不命中的问题，源于每个组只有一行，组映射就放开了这个限制，每个组可以有多个行。常采用的组相联结构Cache，每组内有2、4、8、16块，称为2路、4路、8路、16路组相联Cache。组相联结构Cache是前两种方法的折中方案，适度兼顾二者的优点，尽量避免二者的缺点，因而得到普遍采用。

        主存中的各块与Cache的组号之间有固定的映射关系，但可自由映射到对应Cache组中的任何一块。例如，主存中的第0块、第4块……均映射于Cache的第0组，但可映射到Cache第0组中的第0块或第1块；主存的第1块、第5块……均映射于Cache的第1组，但可映射到Cache第1组中的第2块或第3块 。

        

        主存和Cache都分组，主存中一个组内的块数与Cache中的分组数相同，组间采用直接映射，组内采用全相联映射。也就是说，将Cache分成u组，每组v块，主存块存放到哪个组是固定的，至于存到该组哪一块则是灵活的。例如，主存分为256组，每组8块，Cache分为8组，每组2块 。

        组相连映射方式下的主存地址格式如图，先确定主存应该在Cache中的哪一个组，之后组内是全相联映射，依次比较组内的标记，如果有标记相同的Cache，则命中，否则不命中 。

（3）全相连映射

        只有一个组，包含了所有的行。

        全相连映射如图所示，主存中任何一块都可以映射到Cache中的任何一块位置上。全相联映射方式比较灵活，主存的各块可以映射到Cache的任一块中，Cache的利用率高，块冲突概率低，只要淘汰Cache中的某一块，即可调入主存的任一块。但是，由于Cache比较电路的设计和实现比较困难，这种方式只适合于小容量Cache采用。

        

        全相连映射的主存结构就很简单啦，将CPU发出的内存地址的块号部分与Cache所有行的标记进行比较，如果有相同的，则Cache命中，从Cache中读取，如果找不到，则没有命中，从主存中读取。 

5、cache的替换策略？ 

        cache的替换策略想必大家都知道，就是LRU策略，即最近最少使用算法，选择未使用时间最长的cache替换。

6、什么是cache一致性？ 

        多个CPU对某块内存同时读写，就会引起冲突的问题，被称为Cache一致性问题。

  有这样一种情况：

  a.   CPU1读取了一个字节offset，该字节和相邻的数据就都会被写入到CPU1的Cache.

  b.   此时CPU2也读取相同的字节offset，这样CPU1和CPU2的Cache就都拥有同样的数据。

  c.   CPU1修改了offset这个字节，被修改后，这个字节被写入到CPU1的Cache中，但是没有被同步到内存中。

  d.   CPU2 需要访问offset这个字节数据，但是由于最新的数据并没有被同步到内存中，所以CPU2 访问的数据不是最新的数据。

        这种问题就被称为Cache一致性问题，为了解决这个问题大佬们设计了MESI协议，当一个CPU1修改了Cache中的某字节数据时，那么其它的所有CPU都会收到通知，它们的相应Cache就会被置为无效状态，当其他的CPU需要访问此字节的数据时，发现自己的Cache相关数据已失效，这时CPU1会立刻把数据写到内存中，其它的CPU就会立刻从内存中读取该数据。

        MESI协议是通过四种状态的控制来解决Cache一致性的问题：

■ M：代表已修改（Modified） 缓存行是脏的（dirty），与主存的值不同。如果别的CPU内核要读主存这块数据，该缓存行必须回写到主存，状态变为共享（S）.

■ E：代表独占（Exclusive） 缓存行只在当前缓存中，但是干净的（clean）--缓存数据同于主存数据。当别的缓存读取它时，状态变为共享（S）；当前写数据时，变为已修改（M）状态。

■ S：代表共享（Shared） 缓存行也存在于其它缓存中且是干净（clean）的。缓存行可以在任意时刻抛弃。

■ I：代表已失效（Invalidated） 缓存行是脏的（dirty），无效的。

四种状态的相容关系如下：

        这里我们只需要知道它是通过这四种状态的切换解决的Cache一致性问题就好，具体状态机的控制实现太繁琐，就不多介绍了，这是状态机转换图，是不是有点懵 

7、cache的组织方式

（1）虚拟高速缓存（VIVT）

        我们首先介绍的是虚拟高速缓存，这种cache硬件设计简单。在cache诞生之初，大部分的处理器都使用这种方式。虚拟高速缓存以虚拟地址作为查找对象。如下图所示：

        虚拟地址直接送到cache控制器，如果cache hit。直接从cache中返回数据给CPU。如果cache miss，则把虚拟地址发往MMU，经过MMU转换成物理地址，根据物理地址从主存(main memory)读取数据。但是，正是使用了虚拟地址作为tag，所以引入很多软件使用上的问题。操作系统在管理高速缓存正确工作的过程中，主要会面临两个问题。歧义(ambiguity)和别名(alias)。为了保证系统的正确工作，操作系统负责避免出现歧义和别名。 

• 歧义(ambiguity)

        歧义是指不同的数据在cache中具有相同的tag和index，cache控制器判断是否命中cache的依据是tag和index，因此在这种情况下，chche控制器根本没有办法区别不同的数据，这就产生了歧义。什么情况下发生歧义？我们知道不同的物理地址存储不同的数据，只要相同的虚拟地址映射不同的物理地址就会产生歧义。操作系统如何避免歧义的发生呢？当我们进程切换时，可以选择flush所有的cache。flush cache操作有两步：

①、使主存器有效，针对write back高速缓存，首先应该使主存储器有效，保证已经修改数据的cache写回主存储器，避免修改的数据丢失。

②、置位invalid，让高速缓存无效，保证切换后的进程不会错误的命中上一个进程的缓存数据。

TLB歧义问题：

        多进程下，不同进程相同的虚拟地址空间可以映射不同的物理地址；例如，进程A将地址0x2000映射物理地址0x4000。进程B将地址0x2000映射物理地0x5000。当进程A执行的时候将0x2000对应0x4000的映射关系缓存到TLB中。当切换B进程的时候，B进程访问0x2000的数据，会由于命中TLB从物理地址0x4000取数据，这就造成了歧义。

        如何消除这种歧义？我们可以借鉴VIVT数据cache的处理方式，在进程切换时将整个TLB无效。切换后的进程都不会命中TLB，但是会导致性能损失。

如何避免flush TLB:

        我们知道Linux如何区分不同的进程？每个进程拥有一个独一无二的进程ID。如果TLB在判断是否命中的时候，除了比较tag以外，再额外比较进程ID该多好呢！这样就可以区分不同进程的TLB表项。进程A和B虽然虚拟地址一样，但是进程ID不一样，自然就不会发生进程B命中进程A的TLB表项。

        所以，TLB添加一项ASID(Address Space ID)的匹配。ASID就类似进程ID一样，用来区分不同进程的TLB表项。这样在进程切换的时候就不需要flush TLB。但是仍然需要软件管理和分配ASID。

如何管理ASID：   

        ASID和进程ID肯定是不一样的，别混淆二者。进程ID取值范围很大。但是ASID一般是8或16 bit。所以只能区分256或65536个进程。

        我们的例子就以8位ASID说明。所以我们不可能将进程ID和ASID一一对应，我们必须为每个进程分配一个ASID，进程ID和每个进程的ASID一般是不相等的。每创建一个新进程，就为之分配一个新的ASID。当ASID分配完后，flush所有TLB，重新分配ASID。所以，如果想完全避免flush TLB的话，理想情况下，运行的进程数目必须小于等于256。

        管理ASID上需要软硬结合。Linux kernel为了管理每个进程会有个task_struct结构体，我们可以把分配给当前进程的ASID存储在这里。页表基地址寄存器有空闲位也可以用来存储ASID。

        当进程切换时，可以将页表基地址和ASID(可以从task_struct获得)共同存储在页表基地址寄存器中。当查找TLB时，硬件可以对比tag以及ASID是否相等(对比页表基地址寄存器存储的ASID和TLB表项存储的ASID)。如果都相等，代表TLB hit。否则TLB miss。当TLB miss时，需要多级遍历页表，查找物理地址。然后缓存到TLB中，同时缓存当前的ASID。

更上一层楼： 

        我们知道内核空间和用户空间是分开的，并且内核空间是所有进程共享。

        既然内核空间是共享的，进程A切换进程B的时候，如果进程B访问的地址位于内核空间，完全可以使用进程A缓存的TLB。但是现在由于ASID不一样，导致TLB miss。

        我们针对内核空间这种全局共享的映射关系称之为global映射。针对每个进程的映射称之为non-global映射。所以，我们在最后一级页表中引入一个bit(non-global (nG) bit)代表是不是global映射。

        当虚拟地址映射物理地址关系缓存到TLB时，将nG bit也存储下来。当判断是否命中TLB时，当比较tag相等时，再判断是不是global映射，如果是的话，直接判断TLB hit，无需比较ASID。当不是global映射时，最后比较ASID判断是否TLB hit。

        

什么时候应该flush TLB:    

        我们再来最后的总结，什么时候应该flush TLB。

• 当ASID分配完的时候，需要flush全部TLB。ASID的管理可以使用bitmap管理，flush TLB后clear整个bitmap。

• 当我们建立页表映射的时候，就需要flush虚拟地址对应的TLB表项。第一印象可能是修改页表映射的时候才需要flush TLB，但是实际情况是只要建立映射就需要flush TLB。原因是，建立映射时你并不知道之前是否存在映射。例如，建立虚拟地址A到物理地址B的映射，我们并不知道之前是否存在虚拟地址A到物理地址C的映射情况。所以就统一在建立映射关系的时候flush TLB。

• 别名(alias)

        当不同的虚拟地址映射相同的物理地址，而这些虚拟地址的index不同，此时就发生了别名现象(多个虚拟地址被称为别名)。通俗点来说就是指同一个物理地址的数据被加载到不同的cacheline中就会出现别名现象。

        针对共享数据所在页的映射方式采用nocache映射。例如上面的例子中，0x2000和0x4000映射物理地址0x8000的时候都采用nocache的方式，这样不通过cache的访问，肯定可以避免这种问题。但是这样就损失了cache带来的性能好处。这种方法既适用于不同进程共享数据，也适用于同一个进程共享数据。如果是不同进程之间共享数据，还可以在进程切换时主动flush cache(使主存储器有效和使高速缓存无效)的方式避免别名现象。但是，如果是同一个进程共享数据该怎么办？除了nocache映射之外，还可以有另一种解决方案。这种方法只针对直接映射高速缓存，并且使用了写分配机制有效。在建立共享数据映射时，保证每次分配的虚拟地址都索引到相同的cacheline。这种方式，后面还会重点说 。

（2）物理高速缓存（PIPT）

   基于对VIVT高速缓存的认识，我们知道VIVT高速缓存存在歧义和名别两大问题。主要问题原因是：tag取自虚拟地址导致歧义，index取自虚拟地址导致别名。所以，如果想让操作系统少操心，最简单的方法是tag和index都取自物理地址。物理的地址tag部分是独一无二的，因此肯定不会导致歧义。而针对同一个物理地址，index也是唯一的，因此加载到cache中也是唯一的cacheline，所以也不会存在别名。我们称这种cache为物理高速缓存，简称PIPT(Physically Indexed Physically Tagged)，PIPT工作原理如下图所示。

        CPU发出的虚拟地址经过MMU转换成物理地址，物理地址发往cache控制器查找确认是否命中cache。虽然PIPT方式在软件层面基本不需要维护，但是硬件设计上比VIVT复杂很多。因此硬件成本也更高。同时，由于虚拟地址每次都要翻译成物理地址，因此在查找性能上没有VIVT方式简洁高效，毕竟PIPT方式需要等待虚拟地址转换物理地址完成后才能去查找cache。如果系统采用的PIPT的cache，那么软件层面基本不需要任何的维护就可以避免歧义和别名问题。这是PIPT最大的优点。现在的CPU很多都是采用PIPT高速缓存设计。在Linux内核中，可以看到针对PIPT高速缓存的管理函数都是空函数，无需任何的管理。

（3）物理标记的虚拟高速缓存（VIPT）

         为了提升cache查找性能，我们不想等到虚拟地址转换物理地址完成后才能查找cache。因此，我们可以使用虚拟地址对应的index位查找cache，与此同时(硬件上同时进行)将虚拟地址发到MMU转换成物理地址。当MMU转换完成，同时cache控制器也查找完成，此时比较cacheline对应的tag和物理地址tag域，以此判断是否命中cache。我们称这种高速缓存为VIPT(Virtually Indexed Physically Tagged)。

        VIPT以物理地址部分位作为tag，因此我们不会存在歧义问题。但是，采用虚拟地址作为index，所以可能依然存在别名问题。是否存在别名问题，需要考虑cache的结构，我们需要分情况考虑。      

• VIPT Cache为什么不存在歧义

        在这里重点介绍下为什么VIPI Cache不存在歧义。假设以32位CPU为例，页表映射的最小单位是4KB，我们假设虚拟地址<12:4>位（这是一个有别名问题的VIPT Cache）作为index，于此同时将虚拟地址<31:12>发送到MMU转换得到物理地址的<31:12>，这里我们把<31:12>最为tag，并不是<31:13>,这个地方很关键，也就是说VIPT的tag取决于物理页大小的剩余位数，而不是去掉index和offset的剩余位数，物理tag是唯一的，所以不会存在歧义。

• VIPT Cache的别名问题

        设系统使用的是直接映射高速缓存，cache大小是8KB，cacheline大小是256字节。这种情况下的VIPT就存在别名问题。因为index来自虚拟地址位<12...8>，虚拟地址和物理地址的位<11...8>是一样的，但是bit12却不一定相等。假设虚拟地址0x0000和虚拟地址0x1000都映射相同的物理地址0x4000。那么程序读取0x0000时，系统将会从物理地址0x4000的数据加载到第0x00行cacheline。然后程序读取0x1000数据，再次把物理地址0x4000的数据加载到第0x10行cacheline。这不，别名出现了。相同物理地址的数据被加载到不同cacheline中。

• VIPT Cache什么情况不存在别名

        我们知道VIPT的优点是查找cache和MMU转换虚拟地址同时进行，所以性能上有所提升。歧义问题虽然不存在了，但是别名问题依旧可能存在，那么什么情况下别名问题不会存在呢？Linux系统中映射最小的单位是页，一页大小是4KB。那么意味着虚拟地址和其映射的物理地址的位<11...0>是一样的。针对直接映射高速缓存，如果cache的size小于等于4KB，是否就意味着无论使用虚拟地址还是物理地址的低位查找cache结果都是一样呢？是的，因为虚拟地址和物理地址对应的index是一样的。这种情况，VIPT实际上相当于PIPT，软件维护上和PIPT一样。如果示例是一个四路组相连高速缓存呢？只要满足一路的cache的大小小于等于4KB，那么也不会出现别名问题。

• 如何解决VIPT Cache别名问题

        我 们接着上面的例子说明。首先出现问题的场景是共享映射，也就是多个虚拟地址映射同一个物理地址才可能出现问题。我们需要想办法避免相同的物理地址数据加载到不同的cacheline中。如何做到呢？那我们就避免上个例子中0x1000映射0x4000的情况发生。我们可以将虚拟地址0x2000映射到物理地址0x4000，而不是用虚拟地址0x1000。0x2000对应第0x00行cacheline，这样就避免了别名现象出现。因此，在建立共享映射的时候，返回的虚拟地址都是按照cache大小对齐的地址，这样就没问题了。如果是多路组相连高速缓存的话，返回的虚拟地址必须是满足一路cache大小对齐。在Linux的实现中，就是通过这种方法解决别名问题。

总结

        VIVT Cache问题太多，软件维护成本过高，是最难管理的高速缓存。所以现在基本只存在历史的文章中。现在我们基本看不到硬件还在使用这种方式的cache。现在使用的方式是PIPT或者VIPT。如果多路组相连高速缓存的一路的大小小于等于4KB，一般硬件采用VIPT方式，因为这样相当于PIPT，岂不美哉。当然，如果一路大小大于4KB，一般采用PIPT方式，也不排除VIPT方式，这就需要操作系统多操点心了。

8、如何巧妙的利用CPU cache编程？

const int row = 1024;
const int col = 1024;
int matrix[row][col];

//按行遍历
int sum_row = 0;
for (int r = 0; r < row; r++) {
    for (int c = 0; c < col; c++) {
        sum_row += matrix[r][c];
    }
}
//按列遍历
int sum_col = 0;
for (int c = 0; c < col; c++) {
    for (int r = 0; r < row; r++) {
        sum_col += matrix[r][c];
    }
}

        上面是两段二维数组的遍历方式，一种按行遍历，另一种是按列遍历，乍一看您可能认为计算量没有任何区别，但其实按行遍历比按列遍历速度快的多，这就是CPU Cache起到了作用，根据程序局部性原理，访问主存时会把相邻的部分数据也加载到Cache中，下次访问相邻数据时Cache的命中率极高，速度自然也会提升不少。

        平时编程过程中也可以多利用好程序的时间局部性和空间局部性原理，就可以提高CPU Cache的命中率，提高程序运行的效率

参考文档：

如何利用CPU Cache写出高性能代码，看这些图就够了！ (qq.com)