baron · 3月18日 · 四川

04-多核多cluster多系统之间缓存一致性概述

快速连接

👉👉👉【精选】ARMv8/ARMv9架构入门到精通-目录 👈👈👈


 title=

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一致性),那么怎么维护的呢,上面也说了“使用<font color=blue size=4> 硬件管理的一致性</font>”,下面就以直接写答案的方式,告诉你硬件是怎样维护一致性的。

2. 1 多核缓存一致性

同一个cluster中多core之间的缓存一致性由DSU(big.LITTLE叫SCU)来维护,遵循MESI协议。
在这里插入图片描述

2. 2 多Master之间的缓存一致性

在讲述多Master之间的缓存一致性之前,我们先将Master分为以下几类:

  • ACE Master : 如 big.LITTLE cluster 或 DSU cluster
  • CHI Master : 如 big.LITTLE cluster 或 DSU cluster
  • ACE-lite Master: 如 GPU cluster
  • I/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. 3 dynamIQ架构同一个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 StateDefinition
Modified (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。<font color=red size=4>请记住arm主流core在使用的是MESI</font>。所以接下来,我们也不会再介绍和学习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比特位的,不过这一点在arm ARMstrm文档都是找不到的,不过在一些的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-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 可能缓存了该行数据

关注"Arm精选"公众号,备注进ARM交流讨论区。
图片1.png

推荐阅读
关注数
9462
内容数
207
以易懂、渐进、有序的方式,深入探讨ARMv8/ARMv9架构的核心概念。我们将从基础知识开始,逐步深入,覆盖最新的架构,不再纠缠于过时技术。本系列内容包含但不限于ARM基础、SOC芯片基础、Trustzone、gic、异常和中断、AMBA、Cache、MMU等内容,并将持续更新。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息