目录
前言
多核处理器上有一套完整的协议,来保证Cache一致性。比较经典的Cache一致性协议当属 MESI 协议。
单核Cache中每个Cache line有2个标志:dirty 和 valid 标志,它们很好的描述了 Cache 和 Memory (内存)之间的数据关系(数据是否有效,数据是否被修改),而在多核处理器中,多个核会共享一些数据,MESI协议就包含了描述共享的状态。
转自:https://blog.csdn.net/muxiqingyang/article/details/6615199
缓存一致性协议MESI
在 MESI 协议中,每个Cache line有4个状态,可用2个bit表示,它们分别是:
状态 | 描述 |
---|---|
M(Modified) | 这行数据有效,数据被修改了,和内存中的数据不一致,数据只存在于本Cache中。 |
E(Exclusive) | 这行数据有效,数据和内存中的数据一致,数据只存在于本Cache中。 |
S(Shared) | 这行数据有效,数据和内存中的数据一致,数据存在于很多Cache中。 |
I(Invalid) | 这行数据无效 |
- M (Modified)和E (Exclusive)状态的Cache line,数据是独有的,不同点在于M状态的数据是dirty的(和内存的不一致),
- E状态的数据是clean的 (和内存的一致)。
- S (Shared)状态的Cache line,数据和其他Core的Cache共享。只有clean的数据才能被多个Cache共享。
- I (Invalid)表示这个Cache line无效。
注意:
- 对于M和E状态而言总是精确的,他们在和该缓存行的真正状态是一致的,而S状态可能是非一致的。
如果一个缓存将处于S状态的缓存行作废了,而另一个缓存实际上可能已经独享了该缓存行,但是该缓存却不会将该缓存行升迁为E状态,这是因为其它缓存不会广播他们作废掉该缓存行的通知,同样由于缓存并没有保存该缓存行的 copy 的数量,因此(即使有这种通知)也没有办法确定自己是否已经独享了该缓存行。 - 从上面的意义看来E状态是一种投机性的优化:如果一个CPU想修改一个处于S状态的缓存行,总线事务需要将所有该缓存行的 copy 变成 invalid 状态,而修改E状态的缓存不需要使用总线事务。
//--------------------------------------- 分隔符 -------------------------------------//
- E状态示例如下:
只有Core 0访问变量x,它的Cache line状态为E(Exclusive)。
- S状态示例如下:
3个Core都访问变量x,它们对应的Cache line为S(Shared)状态。
- M状态和I状态示例如下:
Core 0修改了x的值之后,这个Cache line变成了 M (Modified) 状态,其他Core对应的 Cache line 变成了 I (Invalid) 状态。
在MESI协议中,每个Cache的Cache控制器不仅知道自己的读写操作,而且也监听(snoop)其它Cache的读写操作。每个Cache line所处的状态根据本核和其它核的读写操作在4个状态间进行迁移。
MESI协议状态迁移图:
在上图中,Local Read 表示本内核读本 Cache 中的值,Local Write 表示本内核写本Cache中的值,Remote Read 表示其它内核读其它Cache中的值,Remote Write 表示其它内核写其它Cache中的值,箭头表示本 Cache line 状态的迁移,环形箭头表示状态不变。
当内核需要访问的数据不在本 Cache 中,而其它 Cache 有这份数据的备份时,本 Cache 既可以从内存中导入数据,也可以从其它 Cache 中导入数据,不同的处理器会有不同的选择。MESI 协议为了使自己更加通用,没有定义这些细节,只定义了状态之间的迁移,下面的描述假设本Cache从内存中导入数据。
状态转移表格1
MESI状态之间的迁移过程如下:
当前状态 | 事件 | 行为 | 下一个状态 |
---|---|---|---|
I(Invalid) | Local Read | 如果其它Cache没有这份数据,本Cache从内存中取数据, Cache line状态变成E;如果其它Cache有这份数据,且状态为M,则将数据更新到内存,本Cache再从内存中取数据,2个Cache 的Cache line状态都变成S;如果其它Cache有这份数据,且状态为S或者E,本Cache从内存中取数据,这些Cache 的Cache line状态都变成S | E/S |
I(Invalid) | Local Write | 从内存中取数据,在Cache中修改,状态变成M;如果其它Cache有这份数据,且状态为M,则要先将数据更新到内存;如果其它Cache有这份数据,则其它Cache的Cache line状态变成I | M |
I(Invalid) | Remote Read | 既然是Invalid,别的核的操作与它无关 | I |
I(Invalid) | Remote Write | 既然是Invalid,别的核的操作与它无关 | I |
E(Exclusive) | Local Read | 从Cache中取数据,状态不变 | E |
E(Exclusive) | Local Write | 修改Cache中的数据,状态变成M | M |
E(Exclusive) | Remote Read | 数据和其它核共用,状态变成了S | S |
E(Exclusive) | Remote Write | 数据被修改,本Cache line不能再使用,状态变成I | I |
S(Shared) | Local Read | 从Cache中取数据,状态不变 | S |
S(Shared) | Local Write | 修改Cache中的数据,状态变成M,其它核共享的Cache line状态变成I | M |
S(Shared) | Remote Read | 状态不变 | S |
S(Shared) | Remote Write | 数据被修改,本Cache line不能再使用,状态变成I | I |
M(Modified) | Local Read | 从Cache中取数据,状态不变 | M |
M(Modified) | Local Write | 修改Cache中的数据,状态不变 | M |
M(Modified) | Remote Read | 这行数据被写到内存中,使其它核能使用到最新的数据,状态变成S | S |
M(Modified) | Remote Write | 这行数据被写到内存中,使其它核能使用到最新的数据,由于其它核会修改这行数据,状态变成I | I |
状态转移表格2
状态 | 触发本地读取 | 触发本地写入 | 触发远端读取 | 触发远端写入 |
---|---|---|---|---|
M状态(修改) | 本地cache:M 触发cache:M 其他cache:I | 本地cache:M 触发cache:M 其他cache:I | 本地cache:M→E→S 触发cache:I→S 其他cache:I→S 同步主内存后修改为E, 同步触发、其他 cache 后 本地、触发、其他 cache 修改为 S | 本地cache:M→E→S→I 触发cache: I →S→E→M 其他cache:I→S→I 同步和读取一样,同步完成后 触发cache改为M, 本地、其他cache改为I |
E状态(独享) | 本地cache:E 触发cache:E 其他cache:I | 本地cache:E→M 触发cache:E→M 其他cache:I 本地cache变更为M, 其他cache应当是I | 本地cache:E→S 触发cache:I→S 其他cache:I→S 当其他cache要读取该数时, 本地、触发、其他 cache 修改为 S | 本地cache:E→S→I 触发cache: I →S→E→M 其他cache:I→S→I 当触发cache修改本地cache E 数据时, 将本地、触发、其他cache修改为S. 然后触发cache修改为独享, 其他、本地cache修改为I , 触发cache再x修改为M |
S状态(共享) | 本地cache:S 触发cache:S 其他cache:S | 本地cache:S→E→M 触发cache:S→E→M 其他cache:S→I 当本地cache修改时, 本地cache修改为E, 其他cache修改为I, 然后再将本地cache修改为M | 本地cache:S 触发cache:S 其他cache:S | 本地cache:S→I 触发cache:S→E→M 其他cache:S→I 当触发cache要修改本地M数据时, 触发cache修改为E, 本地、其他cache改为I , 触发cache再次修改为M |
I状态(无效) | 本地cache:I→S 或 I→E 触发cache:I→S 或 I→E 其他cache:E、M、I→S 、I 本地、触发cache将从I修改为S 或者E , 其他cache将从E、M、I变为S或者I | 本地cache: I→S→E→M 触发cache: I→S→E→M 其他cache: M、E、S→S→I | 既然是本cache是I, 其他cache操作与它无关 | 既然是本cache是I, 其他cache操作与它无关 |
- 下图示意了,当一个cache line的调整的状态的时候,另外一个cache line 需要调整的状态。
M | E | M | I | |
---|---|---|---|---|
M | × | × | × | √ |
E | × | × | × | √ |
S | × | × | I | √ |
I | √ | √ | √ | √ |
- 举个栗子来说:
- 假设cache 1 中有一个变量x = 0的cache line 处于S状态(共享)。
- 那么其他拥有x变量的cache 2、cache 3等x的cache line调整为S状态(共享)或者调整为 I 状态(无效)。
执行流程
多核缓存协同操作
假设有三个CPU A、B、C,对应三个缓存分别是cache a、b、 c。在主内存中定义了x的引用值为0。
单核读取
-
那么执行流程是:
-
CPU A发出了一条指令,从主内存中读取x。
-
从主内存通过bus读取到缓存中(远端读取Remote read),这是该Cache line修改为E状态(独享).
双核读取
- 那么执行流程是:
- CPU A发出了一条指令,从主内存中读取x。
- CPU A从主内存通过bus读取到 cache a中并将该cache line 设置为E状态。
- CPU B发出了一条指令,从主内存中读取x。
- CPU B试图从主内存中读取x时,CPU A检测到了地址冲突。这时CPU A对相关数据做出响应。此时x 存储于cache a和cache b中,x在chche a和cache b中都被设置为S状态(共享)。
修改数据
- 那么执行流程是:
- CPU A 计算完成后发指令需要修改x.
- CPU A 将x设置为M状态(修改)并通知缓存了x的CPU B, CPU B将本地cache b中的x设置为I状态(无效)
- CPU A 对x进行赋值。
同步数据
- 那么执行流程是:
- CPU B 发出了要读取x的指令。
- CPU B 通知CPU A,CPU A将修改后的数据同步到主内存时cache a 修改为E(独享)
- CPU A同步CPU B的x,将cache a和同步后cache b中的x设置为S状态(共享)。
MESI优化和他们引入的问题
- 缓存的一致性消息传递是要时间的,这就使其切换时会产生延迟。当一个缓存被切换状态时其他缓存收到消息完成各自的切换并且发出回应消息这么一长串的时间中CPU都会等待所有缓存响应完成。可能出现的阻塞都会导致各种各样的性能问题和稳定性问题。
CPU切换状态阻塞解决-存储缓存(Store Bufferes)
- 比如你需要修改本地缓存中的一条信息,那么你必须将I(无效)状态通知到其他拥有该缓存数据的CPU缓存中,并且等待确认。等待确认的过程会阻塞处理器,这会降低处理器的性能。应为这个等待远远比一个指令的执行时间长的多。
Store Bufferes
- 为了避免这种CPU运算能力的浪费,Store Bufferes被引入使用。处理器把它想要写入到主存的值写到缓存,然后继续去处理其他事情。当所有失效确认(Invalidate Acknowledge)都接收到时,数据才会最终被提交。
这么做有两个风险
Store Bufferes的风险
- 就是处理器会尝试从存储缓存(Store buffer)中读取值,但它还没有进行提交。这个的解决方案称为Store Forwarding,它使得加载的时候,如果存储缓存中存在,则进行返回。
- 保存什么时候会完成,这个并没有任何保证。
value = 3;
void exeToCPUA(){
value = 10;
isFinsh = true;
}
void exeToCPUB(){
if(isFinsh){
//value一定等于10?!
assert value == 10;
}
}
-
试想一下开始执行时,CPU A保存着finished在E(独享)状态,而value并没有保存在它的缓存中。(例如,Invalid)。在这种情况下,value会比finished更迟地抛弃存储缓存。完全有可能CPU B读取finished的值为true,而value的值不等于10。
即 isFinsh 的赋值在value 赋值之前。 -
这种在可识别的行为中发生的变化称为重排序(reordings)。注意,这不意味着你的指令的位置被恶意(或者好意)地更改。
-
它只是意味着其他的CPU会读到跟程序中写入的顺序不一样的结果。
-
顺便提一下NIO的设计和Store Bufferes的设计是非常相像的。
硬件内存模型
- 执行失效也不是一个简单的操作,它需要处理器去处理。另外,存储缓存(Store Buffers)并不是无穷大的,所以处理器有时需要等待失效确认的返回。这两个操作都会使得性能大幅降低。为了应付这种情况,引入了失效队列。它们的约定如下:
- 对于所有的收到的Invalidate请求,Invalidate Acknowlege消息必须立刻发送
- Invalidate并不真正执行,而是被放在一个特殊的队列中,在方便的时候才会去执行。
- 处理器不会发送任何消息给所处理的缓存条目,直到它处理Invalidate。
- 即便是这样处理器已然不知道什么时候优化是允许的,而什么时候并不允许。
- 干脆处理器将这个任务丢给了写代码的人。这就是内存屏障(Memory Barriers)。
写屏障 Store Memory Barrier (a.k.a. ST, SMB, smp_wmb)是一条告诉处理器在执行这之后的指令之前,应用所有已经在存储缓存(store buffer)中的保存的指令。
读屏障Load Memory Barrier (a.k.a. LD, RMB, smp_rmb)是一条告诉处理器在执行任何的加载前,先应用所有已经在失效队列中的失效操作的指令。
void executedOnCpu0() {
value = 10;
//在更新数据之前必须将所有存储缓存(store buffer)中的指令执行完毕。
storeMemoryBarrier();
finished = true;
}
void executedOnCpu1() {
while(!finished);
//在读取之前将所有失效队列中关于该数据的指令执行完毕。
loadMemoryBarrier();
assert value == 10;
}
现在确实安全了。完美无暇!