asp 大型网站开发,网站的架构与建设,好项目推荐平台,网站域名续费多少钱目录 1.思考和质疑2.怎样去维护多核多系统缓存的一致性2.1多核缓存一致性2.2多Master之间的缓存一致性2.3dynamIQ架构同一个core中的L1和L2 cache 3.MESI协议的介绍4.ACE维护的缓存一致性5.软件定义的缓存和替换策略6.动图示例 本文转自 周贺贺#xff0c;baron#xff0c;代… 目录 1.思考和质疑2.怎样去维护多核多系统缓存的一致性2.1多核缓存一致性2.2多Master之间的缓存一致性2.3dynamIQ架构同一个core中的L1和L2 cache 3.MESI协议的介绍4.ACE维护的缓存一致性5.软件定义的缓存和替换策略6.动图示例 本文转自 周贺贺baron代码改变世界ctwArm精选 armv8/armv9trustzone/teesecureboot资深安全架构专家11年手机安全/SOC底层安全开发经验。擅长trustzone/tee安全产品的设计和开发。文章有感而发。 1.思考和质疑
在一个大架构大系统中有哪些一致性需要维护我们先看如下一张架构图。 然后请思考
(1)、core0中的L1和L2 cache有一致性的要求吗缓存和替换策略是怎样的(2)、core0 cache 和 core1 cache的一致性是谁来维护 遵从MESI协议吗(3)、core0 cache 和 core4 cache的是怎么维护一致性的呢(4)、custer0 L3 cache 和 cluster1 L3 cache的一致性是谁来维护遵从什么协议吗(5)、custer0 L3 cache 和 GPU的L2一致性呢遵从什么协议(6)、custer0 L3 cache 和 其它的I/O device Master一致性呢遵从什么协议(7)、DSU、ACE、CHI、CCI、CMN的概念
网上的好多篇博文一提Cache的多核一致性就必然提到MESI、MOESI 然后就开始讲MESI、MOESI维护性原理试问一下您是真的不理解MESI吗您真的需要学习MESI你不理解的是架构吧而不是学什么协议. 既然要学习MESI那么这里也继续提出一些问题
(1)、ARM架构中真的使用MESI了吗 或者是哪一级cache使用了哪一级cache没有使用(2)、MESI是一个协议 是谁来维护的总得有个硬件实现这个协议吧是在ARM Core实现DSU实现(3)、MESI的四种状态分别记录在哪里的(4)、arm现在主流的core到底使用的是MESI还是MOESI
2.怎样去维护多核多系统缓存的一致性
有三种机制可以保持一致性
禁用缓存是最简单的机制但可能会显着降低 CPU 性能。为了获得最高性能处理器通过管道以高频率运行并从提供极低延迟的缓存中运行。缓存多次访问的数据可显着提高性能并降低 DRAM 访问和功耗。将数据标记为“非缓存”可能会影响性能和功耗。软件管理的一致性是数据共享问题的传统解决方案。在这里软件通常是设备驱动程序必须清除或刷新缓存中的脏数据并使旧数据无效以便与系统中的其他处理器或主设备共享。这需要处理器周期、总线带宽和功率。硬件管理的一致性提供了一种简化软件的替代方案。使用此解决方案任何标记为“共享”的缓存数据将始终自动更新。该共享域中的所有处理器和总线主控器看到的值完全相同。
然而我们在ARM架构中默认使用的却是第三种 硬件管理的一致性, 意思就是做为一名软件工程师我们啥也不用管了有人帮我们干活虽然如此但我们还是希望理解下硬件原理。
再讲原理之前我们先补充一个场景: 假设在某一操作系统中运行了一个线程该线程不停着操作0x4000_0000地址处内存所以我们当然期望它总是命中着由于系统调度这一次该线程可能跑在cpu0上下一次也许就跑在cpu1上了再下一次也许就是cpu4上了(其实这种行为也叫做CPU migration)
或者举个这样的场景也行 在Linux Kernel系统中定义了一个全局性的变量然后多个内核线程(多个CPU)都会访问该变量.
在以上的场景中都存在一块内存(如0x4000_0000地址处内存)被不同的ARM CORE来访问这样就会出现了该数据在main-memory、cluster cache、core cache不一致的情况, 复杂点场景可能还会考虑cluster chache和other Master(如GPU) cache的一致性情况。
既然出现了数据在内存和不同的cache中的不一致的情况那么就需要解决这个问题也叫维护cache一致性那么怎么维护的呢上面也说了“使用 硬件管理的一致性”下面就以直接写答案的方式告诉你硬件是怎样维护一致性的。
2.1多核缓存一致性
同一个cluster中多core之间的缓存一致性由DSU(big.LITTLE叫SCU)来维护遵循MESI协议。
2.2多Master之间的缓存一致性
在讲述多Master之间的缓存一致性之前我们先将Master分为以下几类
ACE Master : 如 big.LITTLE cluster 或 DSU clusterCHI Master : 如 big.LITTLE cluster 或 DSU clusterACE-lite Master 如 GPU clusterI/O Device Master : 如 DMA 以下是多Master之间的缓存一致性的结论首先CHI/ACE总线都是支持MESI协议数据传输的Master与I/O Device Master之间没有一致性因为I/O Device没有链接到CCI/CMN缓存互联总线上。多个ACE/CHI Master之间的缓存一致性是否遵循MESI要具体情况具体分析简而言之就是(1) 如果两个Master都支持带MESI状态位支持带有MESI信号的读写那么这两个Master缓存一致性是遵从MESI协议的(2) 如果有一个Master不支持带MESI状态位那么这个Master就无法支持带有MESI信号的读写那么这两个Master缓存一致性是不遵从MESI协议的(3) Master的MESI状态位是在该Master的cache的TAG中。ACE/CHI Master和ACE-lite Master之间的缓存一致性是不遵从MESI协议的。这主要是因为ACE/CHI Master无法snoop ACE-lite Master的内存而ACE-lite Master却可以snoop ACE/CHI Master的内存总得来说这不是一个完整的MESI协议。
举一个最常见的例子两个DSU cluster的L3 cache中的TAG中是有MESI比特位的这两个DSU通过ACE/CHI 接口发起的读写是带有MESI信号的所以他们是支持MESI协议的。 再举一个例子一个DSU cluster 和一个接到SMMU上的DMA此时正好对应一个是ACE/CHI Master一个ACE-lite Master由于DMA/SMMU中并没有MESI状态位他们也不会发起带有MESI信号的读写所以这两个Master之间是不支持MESI协议的。
2.3dynamIQ架构同一个core中的L1和L2 cache
dynamIQ架构core中的L1和L2 cache不存在缓存一致性的问题但有分配和替换策略。
我们先看一下DynamIQ架构中的cache中新增的几个概念
(1) Strictly inclusive: 所有存在L1 cache中的数据必然也存在L2 cache中(2) Weakly inclusive: 当miss的时候数据会被同时缓存到L1和L2但在之后L2中的数据可能会被替换(3) Fully exclusive: 当miss的时候数据只会缓存到L1
其实inclusive/exclusive属性描述的正是是 L1和L2之间的替换策略这部分是硬件定死的软件不可更改的。
我们再以 ARMV9 cortex-A710 为例查看其TRM手册得知
L1 I-cache和L2之间是 weakly inclusive的L1 D-cache和L2之间是 strictly inclusive的 也就是说当发生D-cache发生miss时数据缓存到L1 D-cache的时候也会被缓存到L2 Cache中当L2 Cache被替换时L1 D-cache也会跟着被替换当发生I-cache发生miss时数据缓存到L1 I-cache的时候也会被缓存到L2 Cache中当L2 Cache被替换时L1 I- cache不会被替换 所以总结一下就是 L1 和 L2之间的cache的替换策略针对I-cache和D-cache可以是不同的策略每一个core都有每一个core的做法这部分是硬件决定的请查阅你使用core的TRM手册。
3.MESI协议的介绍
本协议适用于
big.LITTLE架构中多核缓存一致性dynamIQ架构中多核缓存一致性多cluster之间缓存一致性 其实也适用于不同cluster之间多核的缓存一致性 然后接下来我们开始学习MESI协议注意着仅仅是一个协议 它既不是软件也不是硬件算上一个标准吧。 首先是Modified Exclusive Shared Invalid (MESI) 协议中定义了4个状态:
MESI StateDefinitionModified (M)这行数据有效数据已被修改和内存中的数据不一致数据只存在于该高速缓存中Exclusive (E)这行数据有效数据和内存中数据一致数据只存在于该高速缓存中Shared (S)这行数据有效数据和内存中数据一致多个高速缓存有这行数据的副本Invalid (I)这行数据无效
其次在ARM的部分的core中定义了第五种状态Shared Modified这种称之为MOESI 协议. 我查询大量的Core的TRM手册信息如下
使用MESI协议的core有A710 A510 A78 A77 A76 A75 A72 A57 A55…使用MOESI协议的core有A7 A15 A53
发现问题了没 并不是网上主流博客所说arm一般都用MOESI。请记住arm主流core在使用的是MESI。所以接下来我们也不会再介绍和学习MOESI了。 然后我们通过数据流图的方式观看下MESI这四种状态的情况: MESI状态之间的切换: Events: RH Read Hit RMS Read miss, shared RME Read miss, exclusive WH Write hit WM Write miss SHR Snoop hit on read SHI Snoop hit on invalidate RU LRU replacement Bus Transactions: Push Write cache line back to memory Invalidate Broadcast invalidate Read Read cache line from memory 学到这里我们对多核之间缓存一致性也有了大概的理解我们也知道了MESI是干啥的了那么我们继续抛几个问题 (1)、为什么说“多核之间的缓存一致性遵从MESI协议是DSU/SCU来维护”的
其实吧这也不是我说的这来自ARM官方文档
对于big.LITTLE架构SCU是这样描述的 对于dynamIQ架构DSU文档中这样描述的 (2)、MESI的状态位记录在哪里的 以 ARMV9 cortex-A710 为例记录在core cache的TAG中的BIT[1:0]中即在TAG中。 对于big.LITTLE架构SCU的L2 cache、dynamIQ架构的DSU L3 cache中的TAG中也都是有MESI比特位的不过这一点在arm ARMs和trm文档都是找不到的不过在一些的PPT上是可以看到的。
4.ACE维护的缓存一致性
ACE master是接到 CCI 缓存互联总线上的 在 CCI Interconnect中其实也是有一个Snoop Filter单元。 ACE协议和Snoop filter单元一起来完成了ACE Master之间的缓存一致性。 snoop filter的主要作用用于记录存储在ACE中的缓存。
Snoop Filter可以在未命中的情况下响应侦听事务并侦听适当的主控只有在命中的情况下。Snoop Filter条目通过观察来自 ACE 主节点的事务来维护以确定何时必须分配和取消分配条目。
Snoop Filter可以响应多个一致性请求而无需向所有master广播ACE 接口。例如如果地址不在任何缓存中则Snoop Filter会以未命中和将请求定向到内存。如果地址在处理器缓存中则请求被视为命中并且指向在其缓存中包含该地址的 ACE 端口。
以下也举了一个多cluster之间缓存一致性的示例A53 cluster读取A57 cluster缓存一致性数据。
(1). Cortex-A53 cluster 发出 Coherent Read Request。(2). CCI-400 将请求传递Request以窥探 Cortex-A57 cluster 缓存。(3). 收到请求后Cortex-A57 cluster会检查其数据缓存的可用性并以所需信息进行响应。(4). 如果请求的数据在缓存中CCI-400 将数据从 Cortex-A57 cluster移动到 Cortex-A53 cluster从而导致 Cortex-A53 cluster中的缓存行填充。
5.软件定义的缓存和替换策略
以上的multi cores、multi cluster、system之间的缓存策略或协议都是由硬件决定软件改不了。那么我们软件可以做什么呢 其实在软件的MMU页表的entry中的属性位中是可以定义该页面内存的缓存策略的。 如果软件定义了内存位non-cacheable或non-shareable那么以上的硬件维护的一致性将不会生效。 接下来对软件定义的缓存策略做了一个小小的总结。
总结了一下shareable、cacheable属性对缓存策略的影响
-Non-cacheablewrite-backcacheablewrite-through cacheablenon-shareable数据不会缓存到cache对于观察则而言又相当于outer-shareablecore访问该内存时数据只缓存的到Core的 cache 中不会缓存到其它cache中同左侧inner-shareable数据不会缓存到cache对于观察则而言又相当于outer-shareablecore访问该内存时数据只会缓存到core的cache和 cluster的 cache中该地址的TAG也不会存到snoop filter中即不会被其它ACE Master snoop同左侧outer-shareable数据不会缓存到cache对于观察则而言又相当于outer-shareablecore访问该内存时数据只会缓存到core的cache和 cluster的 cache中该地址的TAG会存到snoop filter中会被其它ACE Master snoop同左侧
6.动图示例 前置条件 dynamIQ架构、L1 Data weakly inclusive、读写的内存配置位outer-shareable/write-back cacheable 步骤: (1)、core0 读取了一行数据数据缓存到了core0的L1 Dcache、L2 cache(2)、随后core0的L2 中的数据是有可能会被替换出(3)、core1 也读取了该行数据数据缓存到了core1的L1 Dcache、L2 cache、L3 cache(4)、随后core1的L2 中的数据也是有可能会被替换出(5)、core4 也读取了该行数据数据缓存到了core4的L1 Dcache、L2 cache(6)、随后core4的L2 中的数据也是有可能会被替换出(7)、至此core0的L1、core1的L1、cluster0的L3、core4的L1 中都缓存了该数据。core0的L2、core1的L2、core4的L2 可能缓存了该行数据 推荐
ARMv8/ARMv9架构从入门到精通 --博客专栏《Armv8/Armv9架构从入门到精通 第二期》 --大课程8天入门ARM架构 --入门课程
