baron ( 名:代码改变世界ctw),九年手机安全/SOC底层安全开发经验。擅长trustzone/tee安全产品的设计和开发
阅码场付费会员专业交流群
专业群介绍:
彭伟林-阅码场内核性能与稳定性
本群定位内核性能与稳定性技术交流,覆盖云/ /车/机/芯领域资深内核专家,由阅码场资深讲师彭伟林主持。
甄建勇-Perf Monitor&Perf Counter
本群定位Perf、cache和CPU架构技术交流,覆盖云/ /车/机/芯领域资深用户,由阅码场资深讲师甄建勇主持。
邓世强-Xenomai与实时优化
本群定位Xenomai与实时优化技术交流,覆盖云/ /车/机/芯领域资深用户,由阅码场资深讲师邓世强和彭伟林共同主持。
周贺贺-Tee和ARM架构
本群定位Tee和ARM架构技术交流,覆盖云/ /车/机/芯领域资深用户,由阅码场资深讲师周贺贺主持。
谢欢-Linux tracers
本群定位Linux tracers技术交流, 覆盖云/ /车/机/芯领域资深用户,由阅码场资深讲师谢欢主持。
?
?
1.思考和质疑
在一个大架构大系统中,有哪些一致性需要维护?我们先看如下一张架构图。
然后请思考:
上的好多篇博文,一提Cache的多核一致性就 必然提到 MESI、MOESI,然后就开始讲 MESI、MOESI维护性原理?试问一下,您是真的不理解MESI吗?您真的需要学习MESI?你不理解的是架构吧,而不是学什么协议. 既然要学习MESI,那么这里也继续提出一些问题:
2.怎样去维护多核多系统缓存的一致性
有三种机制可以保持一致性:
然而,我们在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分为以下几类:
以下是多Master之间的缓存一致性的结论:
举一个最常见的例子:两个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.3 dynamIQ架构同一个core中的L1和L2 cache
dynamIQ架构core中的L1和L2 cache不存在缓存一致性的问题,但有分配和替换策略。
我们先看一下DynamIQ架构中的cache中新增的几个概念:
其实inclusive/exclusive属性描述的正是是 L1和L2之间的替换策略,这部分是硬件定死的,软件不可更改的。
我们再以 ARMV9 cortex–A710为例,查看其TRM手册,得知:
也就是说:
所以总结一下就是 :L1 和 L2之间的cache的替换策略,针对I-cache和D-cache可以是不同的策略,每一个core都有每一个core的做法,这部分是硬件决定的,请查阅你使用core的TRM手册。
3.MESI协议的介绍
本协议适用于:
然后接下来,我们开始学习MESI协议,注意着仅仅是一个协议 ,它既不是软件也不是硬件,算上一个标准吧。首先是Modified Exclusive Shared Invalid (MESI) 协议中定义了4个状态:
MESI State | Definition |
---|---|
Modified (M) | 这行数据有效,数据已被修改,和内存中的数据不一致,数据只存在于该高速缓存中 |
Exclusive (E) | 这行数据有效,数据和内存中数据一致,数据只存在于该高速缓存中 |
Shared (S) | 这行数据有效,数据和内存中数据一致,多个高速缓存有这行数据的副本 |
Invalid (I) | 这行数据无效 |
其次,在ARM的部分的core中,定义了第五种状态 SharedModified,这种称之为 MOESI协议. 我查询大量的Core的TRM手册,信息如下:
发现问题了没?并不是 上主流博客所说,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 LRU = 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比特位的,不过这一点在 armARMs和 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缓存一致性数据。
5.软件定义的缓存和替换策略
以上的multi cores、multi cluster、system之间的缓存策略或协议,都是由硬件决定,软件改不了。那么我们软件可以做什么呢?其实,在软件的MMU页表的entry中的属性位中,是可以定义该页面内存的缓存策略的。如果软件定义了内存位non-cacheable或non-shareable,那么以上的”硬件维护的一致性”将不会生效。接下来对,软件定义的缓存策略做了一个小小的总结。
总结了一下shareable、cacheable属性对缓存策略的影响:
Non-cacheable | write-back
cacheable |
write-through
cacheable |
|
---|---|---|---|
non-shareable |
数据不会缓存到cache
(对于观察则而言,又相当于outer-shareable) |
core访问该内存时,数据只缓存的到Core的 cache 中,不会缓存到其它cache中 | 同左侧 |
inner-shareable |
数据不会缓存到cache
(对于观察则而言,又相当于outer-shareable) |
core访问该内存时,数据只会缓存到core的cache和 cluster的 cache中,该地址的TAG也不会存到snoop filter中,即不会被其它ACE Master snoop | 同左侧 |
outer-shareable |
数据不会缓存到cache
(对于观察则而言,又相当于outer-shareable) |
core访问该内存时,数据只会缓存到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 可能缓存了该行数据
连载文章前两篇:
第一篇: 深入学习Cache系列 1: 带着几个疑问,从Cache的应用场景学起
第二篇: 深入学习Cache系列 2: Cache是如何工作的?概念以及工作过程
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!