快速链接:
.
个人博客笔记导读目录(全部)
- 付费专栏-付费课程 【购买须知】:
- 【精选】ARMv8/ARMv9架构入门到精通-[目录]
网上的好多篇博文,一提Cache的多核一致性就必然提到MESI、MOESI
,然后就开始讲MESI、MOESI
维护性原理?试问一下,您是真的不理解MES吗?您真的需要学习MESI?你不理解的是架构对吧,而不是学什么鬼协议!
既然您要学了MESI,那么这里也提出几个问题:
(1)、ARM架构中真的使用MESI了吗?
(2)、MESI是一个协议? 是谁来维护的?总得有个硬件实现这个协议吧,是在ARM Core中? CCI-400中?SCU中?DSU中?
(3)、MESI的四种状态,分别记录在哪里的?
然后,是有三种机制可以保持一致性:
燃鹅,我们使用的却是第三种 硬件管理的一致性, 意思就是:做为一名软件工程师,我们啥也不用管了,有人帮我们干活,虽然如此,但我们还是希望理解下硬件原理。
再讲原理之前,我们先补充一个场景:
假设在某一操作系统中运行了一个线程,该线程不停着操作0x4000_0000地址处内存(所以我们当然期望,它总是命中着),由于系统调度,这一次该线程可能跑在cpu0上,下一次也许就跑在cpu1上了,再下一次也许就是cpu4上了(其实这种行为也叫做CPU migration)
或者举个这样的场景也行:
在Linux Kernel系统中,定义了一个全局性的变量,然后多个内核线程(多个CPU)都会访问该变量.
在以上的场景中,都存在一块内存(如0x4000_0000地址处内存)被不同的ARM CORE来访问,这样就会出现了该数据在main-memory、SCU-0的L2 cache、SCU-1的L2 cache、8个Core的L1 cache不一致的情况。
既然出现了数据在内存和不同的cache中的不一致的情况,那么就需要解决这个问题(也叫维护一致性),那么怎么维护的呢,上面也说了“使用 硬件管理的一致性”,下面就以直接写答案的方式,告诉你硬件是怎样维护一致性的。
我们先看一张老的图(bit.LITTLE架构的)吧
既然您一味着坚持要学习MESI、MOESI
,那么咱也不能不介绍对不,紧跟着大佬们步伐,网上抄一抄(注意:那不叫抄,那叫借鉴)
首先是Modified Exclusive Shared Invalid (MESI) 协议中定义了4个状态:
MESI State | Definition |
---|---|
Modified (M) | 这行数据有效,数据已被修改,和内存中的数据不一致,数据只存在于该高速缓存中 |
Exclusive (E) | 这行数据有效,数据和内存中数据一致,数据只存在于该高速缓存中 |
Shared (S) | 这行数据有效,数据和内存中数据一致,多个高速缓存有这行数据的副本 |
Invalid (I) | 这行数据无效 |
其次,在ARM的很多core中,定义了第五种状态Shared Modified
,这种称之为MOESI
协议. 而ARM使用的则是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
看完以上信息,我们再次总结一下,我们学习cache一致性,我们最大的困惑或瓶颈是啥,是不理解MESI吗?应该还是对架构的理解和认知。学习MESI,不如去学习DSU、CCI-550原理吧。