MESI 协议
- 一,MESI状态释义
- 二,MESI状态转换
- 1 Invalid after Reset
- 2, Invalid => Exclusive
- 3, Exclusive => Modified
- 4 Modified => Shared, Invalid => Shared
- 5 Shared => Invalid, Shared => Modified
- 三,状态转换场景总结
- Invalid to Shared/ Invalid to Exclusive
- Invalid to Modified.
- Shared to Modified.
- Shared to Invalid.
- Exclusive to Modified.
- Exclusive to Invalid.
- Modified to Shared.
- Modified to Invalid.
- 四,参考文档
一,MESI状态释义
ARMv8架构使用 MESI 协议来维护在多个core之间的数据一致性,MESI 协议描述了 L1 Data Cache中的一个共享的cache line的状态可以是:
- M,Modified, Unique Dirty((UD), 只存在于当前cache中(unique),并且该cache line上的数据与下一级存储单元中的数据不同(dirty)。换言之,cache line中最新的数据位于当前cache,其他cache中没有备份 ,cache line中的内容与主存中的不一致。
- E,Exclusive, Unique Clean(UC),数据只存在于当前cache line中,并且为clean的。cache中cache line中的数据于主存中的一致,并且其他core中的cache没有该地址的数据备份,只存在一个cache中。
- S,Shared Clean (SC), Shared ,cache line中的data不一定与主存中的一致,但是shared cache line中的数据是最新的,且存在于多个core中。
- I,Invalid,无效的数据,或者可以说当前cache line里没有数据。
Data Cache Unit (DCU)会将cache line的 MESI状态信息保存在tag RAM和 dirty RAM中,关于如何读取cache line中的MESI信息,将在下篇文章中讲解。本文主要探讨MESI的状态转换过程以及转换示例。
二,MESI状态转换
下图为MESI协议的状态转换图:
接下来,本文将结合一个在多核场景下的状态转换用例,来解释具体的MESI状态转换:
1 Invalid after Reset
假设当前系统有四个core,每个core有自己独立的data cache,在系统上电后,所有core的cache line默认都为 invalid状态:
2, Invalid => Exclusive
然后core0 试图读取内存中地址为 0x44013F00上的数据,在core0 的data cache中会发生read miss以及linefill,与该地址相关的cache line的状态将由Invalid 转为 VE,其中V 为Valid,表明该cacheline中的数据有效。E为Exclusive,表明该数据只在core0中,并且是clean的。
上图中的 invalid状态到Exclusive的转换,也就是下图标红的部分:
3, Exclusive => Modified
之后,core0试图对该地址写入一个新值,该cache line的状态将由VE会变成VDM,其中V为,valid,D为Dirty,表示数据为脏,当前cache line中的数据与主存中的不一致。M 为Modified,表明该cache line中的数据是Unique且Dirty的。
也就是下图标红的部分:
4 Modified => Shared, Invalid => Shared
接下来,让core 1,core2,core3也对对该地址进行读取操作,core0的状态将会从VDM 转为 VS,其他三个core的cache line将由Invalid 转为 VS, S表示Shared。此外,从下图中,也可知,core1,core2,core3读取到的数据是core0 cache中的备份,而不是真正内存中的值。
下图红色部分即上述状态的转换过程:
5 Shared => Invalid, Shared => Modified
接4的步骤, 如果core1 试图对该地址写入一个新值,core0、core2和core3中该cache line的状态将会由Shared 变为 Invalid,而core1的状态将由Shared 变为 Modified(VDM)。此外,由于使用的是write back策略,所以当前的写入操作仅写入到了cache中,主存中的内容仍未改变。
在本示例中,出现了两个core先后对同一个内存地址进行读写操作, core0写入的值(蓝色)由于没有被写回到主存中,之后core1又对该地址写入一个新值(绿色),就把core0写入的值给覆盖了。
下图红色部分即上述状态的转换过程:
三,状态转换场景总结
Invalid to Shared/ Invalid to Exclusive
当一个core对某地址发生了read miss,需要进行linefill的时候,如果检查到其他core里保存着该地址的数据,则发生Invalid to Shared,否则就是Invalid to Exclusive。
Invalid to Modified.
当一个core对某地址发生Write miss,需要进行linefill的时候,会广播消息,通知其他core:如果也保存了该地址的数据(无论是E状态或者是S状态),对该地址上的数据进行invalidate操作。所以根据不同的架构实现,可能会发生dirty cache line的write back或者data corruption。
Shared to Modified.
当一个core对某地址发生Write hit(S状态或者M状态)时,会广播通知其他core将对应该地址的数据(如果其他core中存在,其状态只能是S)给invalidate掉。
Shared to Invalid.
检测到其他core对该地址进行了写操作。
Exclusive to Modified.
当一个core对某地址发生Write hit(E状态)时Write hit,无需发出任何广播消息。
Exclusive to Invalid.
检测到其他core对该地址进行了写操作。
Modified to Shared.
检测到其他core对该地址进行了读操作。 改dirt cache line将会分享给发起读操作的core(invalid to shared)。根据具体的实现架构,可能还会发生write back。
Modified to Invalid.
检测到其他core对该地址进行了写操作。根据具体的实现架构,可能还会发生write back。
四,参考文档
https://handwiki.org/wiki/MESI_protocol
https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/what-39-s-the-difference-between-moesi-and-mesi-cache-coherence-for-poets
https://celery1124.github.io/MESI-protocol/
https://users.cs.utah.edu/~bojnordi/classes/7810/s20/slides/07-snooping.pdf
https://inst.eecs.berkeley.edu/~cs152/sp16/handouts/quiz5sol_s2016.pdf
https://inst.eecs.berkeley.edu/~cs61c/su18/disc/11/Disc11Sol.pdf
https://www.geeksforgeeks.org/cache-coherence-protocols-in-multiprocessor-system/