共享存储多处理机

Report
第六章 共享存储多处理机
1
第一节
共享存储多处理机
一、共享存储系统结构
1、共享存储结构
P1
…
Pn
P1
Pn
P1
C
C
…
IN
…
交叉的Cache
…
交叉的主存
存储器 … 存储器
(a) 共享缓存
(b) 集中式共享存储器
C
总线或IN
存储器
Pn
…
C
存储器
IN
(c) 分布式共享存储器
*体系结构组成:节点结构、互连结构
内容—①通信、互连网络的结构与性能设计;
②共享存储系统的结构与性能设计;
③同步操作的结构与性能设计
2
回下页
回4页
回5页
2、结构对系统性能的影响
*执行时间:T(n)=Tcomput+WTlocaldata+αWTcomm+Tsynch+Tpara
Tlocaldata=HTCache+(1-H)Tmem,Tcomm=T固有+T附加
器件决定了Tcomput的f、Tcache、Tmem
(1)共享Cache结构
T(n)=Tcomput+WTlocaldata+WΔTlocaldata+Tsynch+Tpara
*结构特征:对Cache、MEM带宽要求较高;
IN增加了Tcache、Tmem;
n降低了Cache层次的命中率H
*可扩放性:可扩放性很差,
(WΔTlocaldata随W或n急剧增大,
不能利用Cache访问局部性H,
不能利用MEM访问局部性α)
仅适用于n很小(2~8)的系统
3
转上页
(2)集中共享MEM、总线互连结构
T(n)=Tcomput+WHTCache+W(1-H)Tmem+Tsynch+Tpara
*结构特征:对总线带宽、MEM带宽要求较高, (分时访问冲突)
可利用Cache访问局部性H
*可扩放性:可扩放性较差,
(WTmem增大很快,不能利用α)
仅适用于n较小(20~30)的系统
(3)集中共享MEM、网络互连结构
T(n)=Tcomput+WHTCache+W(1-H)Tmem+Tsynch+Tpara
*结构特征:对IN带宽要求较高, (访存穿过网络)
可利用Cache层次的访存局部性H,
系统扩放时结构变化复杂
*可扩放性:可扩放性一般,
(WTmem增大较快,不能利用α)
仅适用于n一般的系统
4
转2页
(4)分布共享MEM、网络互连结构
T(n)=Tcomput+WTlocaldata+αWTcomm+Tsynch+Tpara
Tlocaldata=HTCache+(1-H)Tmem
Tcomm=T固有+T附加,每次通信Tcomm’=t0+tl+m/r∞-toverlap
*结构特征:可利用Cache和本地MEM访存局部性H和α
*结构与性能:存储系统影响H、T附加,
通信系统影响t0、Tsynch、toverlap及Tpara,
互连网络影响tl、r∞及toverlap
*可扩放性:可扩放性较好,
(W或n增大时结构变化不大,
能用软件优化α和隐藏Tcomm)
适用于n较大的系统
5
转2页
3、本章重点讨论内容
—基于集中式共享的体系结构
(1)通信、互连网络结构与性能设计
*结构设计:共享变量通信结构、总线互连结构;(与单P类似)
*性能设计:与存储系统密切相关
(在存储系统性能设计中讨论)
(2)存储系统结构与性能设计
*结构设计:存储系统结构模型, (与单处理机类似[层次结构])
单级及多级Cache结构的存储系统一致性实现;
*性能设计:存储系统一致性模型(Cache一致性,存储一致性)
的性能设计,通信、总线的性能设计
(3)同步操作结构与性能设计
*结构设计:互斥/点点事件/栅障事件的同步结构/硬件原语;
*性能设计:结构/原语转换、同步权获得/等待/释放的性能设计
6
二、高速缓存一致性
指各P的Cache中数据副本和SM中数据间的一致性
指相对于没有Cache的存储操作结果←┘
1、不一致原因
①绕过Cache的I/O操作(如DMA操作);
②不同P对自身Cache中相同数据副本的异步写操作;
③多处理器中不互相通报的进程迁移
2、Cache一致性解决方法
*第①种原因:禁止法(非仅P访问的数据禁止进入Cache),
刷新法(I/O操作前刷新被改数据副本);
*第②③种原因:刷新法(用一致性协议提前刷新数据副本)
实现方法—监听法(基于总线互连)、目录法(基于网络互连)
7
3、高速缓存一致的存储系统
*存储操作:
单P操作特征—部分操作到达主存、操作发出=完成
P1
主存
…
C
Pn
操作发出=完成
C
W完成=后续R返回最近结果
R完成=后续W不影响R返回值
多P操作特征—无全局串行序(最近/后续无法定义)
*相关概念:
程序序(程序次序)—程序员认为的源程序操作逻辑顺序;
执行序(执行次序)—进程发出的源程序操作实际次序,
MEM操作顺序与执行序相同;
偏序—指所有P对某存储单元的MEM操作次序;
全序—指所有P对所有存储单元的MEM操作次序
8
回下页
*定义:根据程序任何一次执行结果,对所有存储单元的MEM
操作,均可以构造出一个全序,且满足下列条件:
1)实际的执行结果=按该全序的执行结果;
2)进程→存储系统的操作次序=该全序的次序;
3)各读操作返回值=全序中该单元偏序的最后写操作的值
*Cache一致性隐含的性质:
写传播—某P写操作的效果对其他P可见;
写串行化—各P以相同顺序看到对同一单元的所有写操作
P0:
P1:
R1
R5
R4
R2
W3
W3
R1
R4
R4
W2
R3
W2
偏序3
9
回11页
转上页
回21页
三、存储一致性
指源程序的程序次序与进程的执行次序间的一致性
编程人员与系统间有关程序行为的约定←┘
*目标:研究编译程序、硬件对程序行为及性能的影响
*模型:顺序一致性模型、放松的一致性模型
1、顺序一致性模型(SC)
*SC定义:多处理机系统满足下列条件称为是顺序一致的
①程序任何一次执行结果都与所有操作按某一顺序执行
的结果一致;
②在该顺序中各P的执行序和它的程序序一致
*SC对存储操作的约束:
①各进程的执行序=程序序
②访存操作具有原子性
回下页
回22页
按程
序序
P1
P2
…
Pn
…
随机设置
主存
10
*保证顺序一致性的充分条件:
①每个进程按程序序发出存储操作;
②进程发出写操作后,须等待该写操作相对于所有P完成,
才能发出下一个操作;
③进程发出读操作后,须等待该读操作完成及提供所读
数据的写操作完成,才能发出下一个操作
P0:
R1
R5
R2
W3
R4
R3
MEM操作的全序
P1:
R4
条件①
W3
R3
条件②
条件③
*顺序一致性对程序执行序的影响:
要求编译优化(如延迟转移)、体系结构优化(如异步流水)等
不改变存储操作次序(即程序次序)
11
转上页
转9页
回22页
2、放松的一致性模型
*目标:放松程序序对执行序的限制,以提高系统性能
*类型:处理器一致性、弱一致性、释放一致性等
*处理器一致性模型:各P内W遵循程序序(各P间W无要求),
各P内W→R的R可提前(R→R不可以)
P0:
P1:
R1
W1
R2
W2
W2
R2
R3
W3
W4
R1
R3
*弱一致性模型:同步操作与其间存储操作集满足顺序一致性
P0:
P1:
R1
R3
W1
W2
W3
S2
S3
R2
W3
W4
S2
S4
内部可乱序
12
第二节
基于监听的Cache一致性协议
一、一致性协议原理
*Cache块状态:
写直达法--有效态、无效态;
写 回 法—共享态、[独占态]、修改态、无效态
*一致性协议:是一种控制Cache块状态变化、以保证一致性
的分布式算法,可用状态转换图表示
算法策略—有基于作废、基于更新2种
分布式实现—各Cache自行产生状态变化及相应操作
一致性保证—动作满足写传播、写串行化及算法策略要求
*状态获取:通过监听总线上其它P操作的总线事务实现
总线事务—有仲裁、操作2个步骤,具有顺序性和原子性
13
二、VI写直达作废协议
*Cache块状态:有效态(V)--干净块(数据与主存中相同),
该块可同时在多个Cache中存在
无效态(I)—此块不在Cache中[或已作废]
*协议基本思想:满足Cache工作流程需求,写操作时写主存、
通过总线事务通知其它Cache作废该块
*Cache可见操作/事务:
①PrRd、PrWr;②CaInvd(替换伪定义);③BusRd、BusWB
*状态转换图:假设采用不按写分配法写丢失策略
PrWr/BusWB
PrRd/—
BusRd/—
PrWr/BusWB
PrRd/BusRd
V
I
BusWB/—
BusRd/—
BusWB/—
说明:①A/B表示若A事务被某Cache观察到,则其生成B事务
②
表示CPU启动的事务,
表示总线监听命中启动的事务
14
三、MSI写回作废协议
1、协议状态转换图
(1)Cache块状态
*块状态:
修改态(M)—脏块,该块仅同时在一个Cache中存在
共享态(S)—干净块,该块可同时在多个Cache中存在
无效态(I)—此块不在Cache中[或已作废]
某主存块在各Cache中的块状态
P0 Cache
P1 Cache
P2 Cache
I
I
I
S
I
I
I
S
I
I
I
S
S
S
I
S
I
S
I
S
S
S
S
S
M
I
I
I
M
I
I
I
M
15
回17页
(2)协议基本思想
*基于作废策略的Cache工作流程:
不命中
无空闲位置
有空闲位置
PrRd(读) 选择被替换块i;
若块i为M态,写回主存; 调入目标块;
转→
PrWr(写) 转→
状态
CPU操作
命中
完成操作
通知其他Cache作废
目标块、完成操作
*Cache可见操作/事务:
①PrRd、PrWr;②CaInvd(替换伪定义);
③BusRd、BusWB、BusRdX(总线互斥读[调入+通知])
PrRd、PrWr
CaInvd
CPU
CPU
主存
Cache
Cache
BusRd、BusRdX、BusWB
16
回下页
*协议基本思想:
①写-无效策略的体现—
接收到PrWr操作时,产生BusRdX事务(通知作废);
监听到BusRdX事务时,块状态变化为S/M→I(被作废)
②工作流程的实现—
实现工作流程时,产生相应总线事务、状态改变
③总线事务的优化—
监听命中、块为M态时,提供数据(主存接收数据)
Cache1(块a为I态): BusRd
Cache2(块a为M态):
主存(块a为旧数据):
等待
BusRd(续)
BusRd
BusWB
接收数据
优化
发送数据
Cache2抢占总线 主存提供数据
时间
发送数据
接收数据
时间
Cache2提供数据、主存接收数据
块拥有者—块最新数据所在部件(M态的Cache或主存)
17
转上页
(3)协议思想的实现
*PrRd:块为I态时产生BusRd事务(M/S态时不产生)、
改变状态(I→S、S/M不变)
*PrWr:块为S/I态时先产生BusRdX事务(M态时不产生)、
改变状态(I/S/M→M),再在M态写数据
*CaInvd:被替换块为M态时产生BusWB事务(S态时不产生)、
改变状态(M/S→I)
*BusRd:监听命中时响应(M态需提供数据),
改变状态(M/S→S)
*BusRdX:监听命中时响应(M态需提供数据),
改变状态(M/S→I)
*BusWB:监听均不会命中
18
转下页
(4)状态转换图
假设采用按写分配法的写丢失策略
CaInvd/BusWB
PrWr/—
PrRd/—
PrWr/(BusRdX+newPrWr)
M
I
BusRdX/Flush
S
PrRd/—
CaInvd/—
BusRd/—
说明:①实线为处理器操作时的变化,虚线为监听命中时的变化
②Flush指总线事务由本Cache提供数据(否则由主存提供)
③BusRdX在S态时不需要块数据,在I态时需要块数据
19
回上页
回下页
回25页
*状态转换示例:
Pi操作
P1 Cache P2 Cache P3 Cache
中块u状态 中块u状态 中块u状态
总线
事务
数据提供者
原始状态
I
I
I
—
—
P1读u块
S
I
I
BusRd
主存
P3读u块
S
I
S
BusRd
主存
P3写u块
I
I
M
BusRdX
主存
P1读u块
S
I
S
BusRd
P3 Cache①
P2读u块
S
S
S
BusRd
主存
说
明
①主存此时接收并更新块数据
思考:为何BusRdX事务,需包含BusRd功能?
(5)协议总线流量的优化
*减少事务数据量:S态块的BusRdX可用BusUpgr(无数据)代替
*减少事务的数量:块只有一个副本时,PrWr不产生总线事务
20
转上页
2、协议对Cache一致性的保证
*对写传播特性的保证:
Px(执行PrWr操作)
S/I态时
M态时
其它P
写传播性的保证
S/M→I
成为
数据拥有者
I→I
(S/I/M→M)
Px产生BusRdX事务,操作对所有P可见
后续操作由Px提供数据,等价于操作对
所有P可见
*对写串行化特性的保证:
Cache不接收P的其它操作
操作Px: PrWr1
PrRd2
Cache
→BusRdX1→newPrWr1
-------------→BusRd2
(总线事务可保证)写传播
Cache
其他P:
写串行化(总线事务串行化保证
+Cache控制器保证)
------------------→BusRdX1→newPrWr1
PrWr1
21
转9页
回下页
回43页
3、协议对顺序一致性的保证
*对执行序=程序序的保证:
各P需按程序序发出存储操作(与协议无关);
各Cache需按串行方式执行存储操作(PrRd/PrWr)
*对存储操作为原子操作的保证:
Cache需在P的操作完成前不接收新请求; ←本地原子性
Cache需监听总线事务(并响应);
←全局可见(完成)
Cache需在PrWr完成前不放弃总线控制权 ←写原子性
(如在BusRdX与newPrWr间监听命中时插入等待周期)
P0:
P1:
R1
R5
R4
R2
W3
W3
R4
R3
R3
22
转10页
转11页
转上页
回42页
四、MESI写回作废协议
(1)协议基本思想
基于MSI协议,增加状态E(块只有一个副本),
使E态块的PrWr操作不产生总线事务
(2)Cache块状态
修改态(M)—脏块,该块仅同时在一个Cache中存在
独占态(E)—干净块,该块仅同时在一个Cache中存在
共享态(S)—干净块,该块可同时在多个Cache中存在
无效态(I)—此块不在Cache中[或已作废]
某主存块在各Cache中的块状态
P0 Cache
P1 Cache
P2 Cache
I
I
I
S
S
I
S
I
S
I
S
S
S
S
S
E
I
I
I
E
I
I
I
E
M
I
I
I
M
I
I
I
M
23
回下页
(3)协议思想的实现
*PrRd:块为I态时产生BusRd事务(M/E/S态时不产生)、
改变状态(I→E或S、E/S/M不变)
└→由块副本的唯一性(S)决定
*PrWr:块为S/I态时先产生BusRdX事务(E态时不产生)、
改变状态(I/E/S/M→M),再写入数据
*CaInvd:被替换块为M态时产生BusWB事务(E/S态时不产生)、
改变状态(M/E/S→I)
*BusRd:监听命中时响应(监听命中信号S、M态需提供数据),
改变状态(M/E/S→S)
*BusRdX:监听命中时响应(M态需提供数据),
改变状态(M/E/S→I)
*BusWB:监听均不会命中
24
转上页
转下页
(4)状态转换图
PrRd/—
PrWr/—
CaInvd/BusWB
PrWr/(BusRdX+newPrWr)
M
BusRdX/Flush
PrWr/—
CaInvd/—
PrRd/—
I
PrRd/BusRd(S)
BusRdX/—
CaInvd/—
E
BusRd/—
S
PrRd/—
BusRd/—
说明:① BusRd(S)中S表示是否有共享,S有效为有共享
② M/E/S态BusRd监听命中时,向总线发监听命中信号S
25
回上页
转19页
五、Dragon写回更新协议
(1)协议基本思想
写操作时向各Cache刷新数据,写回时才更新主存
(2)Cache块状态
干净的独占态(E)—干净块,仅同时在一个Cache中存在
干净的共享态(Sc)—干净块或脏块,可同时在多个Cache中
存在(全部为Sc态或一个非Sc态)
共享已修改态(Sm)—脏块,可同时在一个Cache中存在 块拥
修
改
态(M)—脏块,同时只在一个Cache中存在 有者
某主存块在各Cache中的块状态
P0 Cache I E I I Sc Sc I Sc Sm Sm Sm I Sc Sc I Sc Sc M I I
P1 Cache I I E I Sc I Sc Sc I Sc Sc Sm Sm Sm Sc I Sc I M I
P2 Cache I I I E I Sc Sc Sc Sc I Sc Sc I Sc Sm Sm Sm I I M
26
回下页
回28页
(3)协议思想的实现
*PrRd:(读命中)不产生总线事务,块状态不变
*PrRdMiss:产生BusRd事务、状态为Sc/E态[信号S决定]
*PrWr:块为Sc/Sm态时产生BusUpd事务(E/M态不产生)、
改变状态(Sc/Sm→Sm/M[S决定]、E/M→M),再写入数据
*PrWrMiss:先产生BusRd事务、状态为Sm/M态(信号S决定),
再写入数据
*CaInvd:Sm/M态时产生BusWB事务,改变状态(E/Sc/Sm/M→I)
*BusRd:监听命中时响应(监听命中信号S、Sm/M态需提供数据),
改变状态(E/Sc→Sc、M/Sm→Sm)
*BusUpd:广播(所写)数据到总线上,监听命中时响应(监听
命中信号S、更新数据),改变状态(Sc/Sm→Sc)
*BusWB:监听命中时(Sc态时)无需响应,状态不变
转上页
转下页
27
(4)状态转换图
CaInvd/—
PrRd/—
BusWB/—
PrRd/—
E
BusRd/—
Sc
PrRdMiss/BusRd(S#)
PrRdMiss/BusRd(S)
I
I
PrWr/BusUpd(S)
PrRd/—
BusRd/Flush
BusRd/—
BusUpd/Update
Sm
PrWrMiss/(BusRd(S)+newPrWr)
PrWr/BusUpd(S#)
BusRd/Flush
M
PrWr/BusUpd(S#)
CaInvd/BusWB
PrRd/—
PrWr/—
PrWrMiss/(BusRd(S#)+newPrWr)
说明:①Flush指总线事务由本Cache提供数据(否则由主存提供)
②Update指本Cache接收总线事务的数据并更新到相应块
28
回上页
转26页
六、一致性协议设计中的相关问题
1、一致性协议设计的基本方法
*协议包含的内容:
协议类型(作废/更新)、协议状态和动作、
低层实现(如总线事务/一致性粒度)等
*协议的性能指标:
总线流量、访存时延
*协议设计的基本方法:分析与模拟方法
①根据应用需求,选择测试程序
②初步设计几种协议(各包含多种参数)
③用模拟器分别测量几种协议的总线流量、访存时延
④根据所测数据,选定一致性协议及其参数
29
回下页
回31页
回34页
2、协议下的总线带宽需求
*协议下的总线带宽计算方法:(基于并行的测试程序)
各种事务数/访问=k次MEM访问的状态转移的总线事务数÷k
总线流量/访问=∑每种事务流量×每种事务次数/访问
总线流量/指令=总线流量/访问×MEM访问总数÷总指令数
总线带宽需求=总线流量/指令×处理速度
*协议下的总线带宽需求:
总线带宽≥协议下的总线带宽×150%
(突发性及可扩展性)
*不同协议的总线带宽需求比较:
协议—MESI、MSI、MSI改进型(S态PrWr产生BusUpgr[非BusRdX])
条件—Cache大小、块大小等均相同、具有普遍性
结论—MESI比MSI改进型略好(约10%),比MSI好较多
30
转上页
回下页
3、协议下的访存时延分析
*协议下的访存时延:
TA=T’命中+F’ ·T失效,
T’命中=T命中+T一致性,F’=F+F一致性
*访存时延与协议参数的关联:
块大小=一致性粒度时
T一致性—与协议的所有内容有关、可能与块大小有关,
所产生的总线流量受协议参数影响;
F一致性—与写策略、协议类型、块大小有关,
不受同一类型协议参数影响(方法相同、流量不同)
T命中、F、T失效—与Cache参数、总线带宽等有关,
与协议参数无关
※协议的选择依据:主要为协议的总线带宽需求!
31
回下页
转上页
转29页
4、协议下的Cache块大小选择的权衡
*扑空类型:
冷启动扑空、容量扑空、冲突扑空,
一致性扑空(分为真共享扑空、伪共享扑空)
*块大小对扑空率的影响:增加块大小时
冷启动、容量、真共享扑空率减少(容量固定时有拐点),
伪共享扑空率增加(优化方法有减小一致性粒度、更新协议等)
*块大小对总线流量的影响:增加块大小时
通信扑空为主时,总线流量增加较快(2~3倍速度)
*Cache块大小选择的权衡:
目标—较小的扑空率、较小的总线流量
权衡—优先扑空率及失效开销,兼顾总线带宽成本
32
转上页
5、更新协议、作废协议的比较
*更新协议的应用特性:
适合一次写多次读共享、不适合多次写一次读共享
*混合协议:
--解决应用不确定性问题
即更新+作废协议,每个块设置一个计数器CNT,本地访
问时CNT←k,收到更新时CNT←CNT-1,CNT=0时作废该块
*不同协议的评测结果:
--基于更新、混合、作废协议
扑空率递增(差距较小)、刷新速率递减(差距较大)
总线流量递减(差距较大)
扑空时延更重要
※一致性协议设计小结:
①协议类型常为作废(很少为更新),
②协议状态常为MESI,
③一致性粒度常为块大小
33
转29页
第三节
基于监听的Cache一致性实现
*Cache一致性协议实现的目标:
正确性—硬件层非原子操作须保持状态转换图的正确性
高性能—存取操作应流水化
(同时允许多个未完成操作)
额外硬件少—优化设计,减少硬件复杂性和成本
一、正确性要求
*满足一致性要求:
满足Cache一致性要求、保持存储一致性模型的语义
*解决死锁与活锁:
死锁处理(避免资源依赖环、检测并消除死锁),活锁处
理(优先级等);挨饿消除(总线仲裁和FIFO队列等)
*处理异常:处理各种异常、从异常中恢复状态
34
二、基于原子总线的单级Cache设计
*假设:MESI作废协议、原子总线(只有一个未完成请求)
*单处理机的Cache结构与原理:
Cmd
Addr
CPU
Data
存储阵列
(SRAM)
比较器
目
录
表
控制器
块状态—I/V、M
控制器--有限状态机
总线操作步骤-请求、等待获取(仲
裁)、地址及命令、等
待响应、数据
System Bus
*设计内容:块标记、状态机、监听系统、非原子状态转换、
写回等
35
回下页
1、Cache控制器和块标记的设计
*操作要求:Cache可同时响应来自处理器和总线的操作
*控制器设计:
分为总线端、处理器端两部分,并能够相互作用
P 端 控 制 器 --与单P的Cache控制器类似
(响应P操作、产生总线事务、改变状态)
BUS端控制器—监听及响应总线事务、改变状态
*块标记设计:
块标记—标记(同单P结构)、状态(M/E/S/I)
要求--支持P端、BUS端的同时访问
实现--①双端口RAM组成的目录表,
②相互拷贝的两个目录表(改写与其他操作互斥)
36
转上页
转下页
*双目录表的Cache结构(一部分):
处理器
Addr
Data
Cmd
比较器
目
录
表
总线端
控制器
比较器
监
听
结
果
目
录
表
Cache
存储阵列
处理器端
控制器
地址 写回缓冲区
比较器
Addr
Cmd
数据缓冲区
Addr
Cmd
System Bus
37
转下页
回上页
回39页
回40页
2、监听结果提交的设计
涉及提交时间、提交格式2个方面
(1)监听结果提交时间的设计
*设计目标:硬件成本低、延迟小(主存决定是否响应)
*可选方案:
①固定监听延迟方案— 延迟=常数(max)
各Cache固定时间内给出监听结果
②可变监听延迟方案-- 延迟=max{所有Cache监听延迟}
各Cache监听完成时给出监听完成信号及监听结果,
③主存维护修改标志方案— 延迟=主存监听延迟
主存每个块维护1位标志(M位),Cache不提交监听结果
*设计结果:可变监听延迟方案(方案②)较优
38
回下页
(2)监听结果提交格式的设计
*基于可变监听延迟的格式设计: 总线中增加三根信号线
监听完成--指示监听是否完成(监听结果是否有效)
监听命中--指示某Cache是否有该块的拷贝
修改状态--指示命中的块是否为修改态(M)
*Cache及主存对监听结果的响应动作: (状态机[部分])
监听结果
完 命 修
成 中 改
1 0
1 1
1 1
总线事务
BusRd
BusRdX
请求方:I→E
主 存:提供数据
请求方:I→S
0 命中方:E/S→S
主 存:提供数据
请求方:I→S
1 命中方:提供数据、M→S
主 存:更新数据
X
BusWB
请求方:M→I
请求方:I/E→M
主 存:提供数据
主 存:更新数据
请求方:I/S→M
命中方:E/S→I
主 存:提供数据
请求方:I→M
命中方:提供数据、M→I
主 存:更新数据
39
回41页
转上页
转37页
3、写回处理的设计
*基本思路:
采用“读失效优先于写”(推迟写、优先读)的方法
*推迟写回的实现:
Cache增设写回缓冲区(WBBuff),WBBuff由控制器管理
有效位
地址
块数据缓冲区
*写回缓冲区的管理:
总线空闲时—产生BusWB(WBBuff内容写回主存)、清除相应行
本地操作命中时— WBBuff数据调回阵列、清除相应行
(图中未标出)
总线监听命中时— 提交监听结果(111),总线响应时从
WBBuff中提供数据、清除相应行
40
回下页
转37页
4、Cache基本结构的设计
2个控制器、2个目录表(同步)、1个写回缓冲区
处理器
Addr
Data
Cmd
比较器
目
录
表
总线端
控制器
比较器
监
听
结
果
目
录
表
Cache
存储阵列
处理器端
控制器
地址 写回缓冲区
比较器
Cmd
Addr
数据缓冲区
Addr
Cmd
System Bus
41
转39页
转上页
回下页
回43页
5、结构设计中的相关问题及解决
(1)非原子性的状态转移问题
*举例:P1及P2欲发BusUpgr、P2获得总线(→P1应发BusRdX)
*解决:方案②较优
①使用中间状态扩展状态转换图
★②将监听结果与自身请求(或事务)比较、并处理
如—修改总线请求,或BusRdX、本地监听命中时使事务无数据阶段
(2)串行化及原子性的性能问题
*术语:写提交—写操作位置确定(新值绑定到存储单元)的时间
写完成—新值写入存储器(单元)的时间
*特性:串行化和原子性不影响写完成、只要求到时候有新值
*解决:可用“提交”代替“完成”,要求是其它Cache在后续事
务前插入作废操作、本地Cache完成写新值前不存在冲突事务
42
转上页
回63页
转22页
(3)死锁问题
*死锁避免:P端和BUS端控制器可并行工作、需相互协调
*活锁避免:本地M态写操作完成前保证不受冲突事务干扰
(如相同地址监听命中时,使“监听完成”信号无效)
*挨饿减少:总线仲裁采用计数器法或FIFO策略
(4)读-改-写原子操作的实现问题
*总线支持读-改-写事务时:无实现问题
*总线不支持读-改-写事务时:方案②较优
①在BusRd与BusRdX间不放弃总线控制权(性能低、易死锁)
②在BusRd与BusRdX间不放弃块控制权(见活锁避免例)
43
回53页
转41页
转21页
三、多级Cache的设计
*假设:原子总线、作废协议
*多级Cache的监听方案选择:方案②较优
P1
Pn
L1$
L1$
L2$
…
处理
L2$
监听
I/O设备
方案①--所有级均监听
Pn
L1$
L1$
L2$
监听
存储器
P1
…
监听
处理
L2$
监听
存储器
I/O设备
方案②--连接总线级监听
*多级Cache的一致性需求:
--基于方案②
①连接总线的Cache间满足一致性
②各级Cache间满足包含性
44
回下页
*包含性的定义:
①上级Cache的内容是下级Cache的子集
←上下相关
②块在上级Cache为拥有态,在下级必是修改态 ←下上相关
*包含性被破坏的原因:
①各级数据访问历史不一致
②不同级Cache个数不同(如I$、D$分离)
③各级间存储块大小不同
*包含性对各级Cache参数的要求:
①下级Cache关联度大于上级;
②各级Cache块大小相同;
③下级Cache容量大于上级
45
转上页
回下页
1、包含性维持的设计
*包含性维持的设计: --扩充一致性的传播机制
①Ln$的总线事务或替换引起的块改变,必须传播到L1$
②L1$写命中的块改变必须传播到所有级
*包含性维持①的实现:方法2较优
方法1—Ln$的所有过程均传递到L1$,由L1$自行处理
方法2—各级的块均设置“包含位”,
“包含位”有效的块的过程才传递到L1$
└→Li$的替换均向下传递
*包含性维持②的实现:
方法1—非Ln$均采用写穿法,立即传递状态与数据
方法2—非Ln$均采用写回法,只立即传递状态,
非L1$均设置MI块状态,监听命中时才传递数据
└→已修改但数据无效
46
转上页
2、一致性事务的传播设计
*一致性事务的传播要求:向上渗透和向下渗透
*向下渗透的设计:
--以PⅡ微机系统为例
操作请求—PrRd、PrWr、CaInvd,新增PrUgr、PrRdX
渗透方法—请求的传递直到碰到适当状态的块或总线为止,
请求的回应逐层向上传递、并更新Cache
PrRd
L1$
(M)
PrWr
命中
缺失
PrRd
L2$
L1$
(M)
PrWr
命中
缺失
L2$
(S)
CaInvd
缺失
BusRd
BusWB
L1$
S→I态
PrUgr PrRdX
(M)
M→I态 PrWr
(S)
S→I态
缺失
(M)
(M)
BusWB
PrWr
M→I态
BusRdX
L2$
(M)
BusWB
47
回下页
*向上渗透的设计:
--以PⅡ微机系统为例
监听事务—BusRd、BusRdX、BusWB
渗透方法—逐层修改状态、直到碰到已修改拷贝为止,
部分事务需将数据送回总线
E/S→I态
M→S态
L1$
M→I态
BusRd
(MI)
BusRdX
MI→S态
M→S态
BusRd
L2$
MI/E/S→I态
M→I态
BusRdX
*一致性对传播过程的要求:
要求—请求/数据的上/下传播过程与总线事务保持互斥
互斥实现—在监听命中、传播未完成时,插入等待周期
※多级Cache结构中,双标记结构已不太重要
转上页
48
第四节
同步操作的设计与实现
一、同步操作
*类型:互斥、点点事件、栅障事件(全局事件)
1、同步事件
*同步事件的组成:
获取方法、等待算法、释放方法
各进程竞争同步权
进程1: {I }
11
进程2:
进程3:
请求
释放
获得
{I12}
请求
{I21}
请求
{I13}
等待
等待
等待
获得
{I31}
获得
释放
{I22}
{I23}
释放
{I32}
{I33}
49
回下页
*实现方法:
获取方法—硬件线路、硬件原语(原子性的读-改-写指令)
影响因素:性能目标及实现思路
等待算法—忙等待、阻塞,先忙等待后阻塞(自适应)
影响因素:等待周期,争用度、硬件原语、机器结构
设计方法:通用算法、多种算法+可选、折中算法
释放方法—硬件线路、普通操作(W)
2、同步操作的性能
*性能指标:获取时延、流量、公平性、可扩放性
*影响因素:硬件原语的性能及适用性、同步算法的优劣
50
回下页
转上页
二、互斥操作的设计
*实现方法:有锁、二元信号量2种
锁—有硬件锁、软件锁2种,等待算法为忙等待型
二元信号量—等待算法为阻塞型
*设计内容:
获取方法(含锁结构及硬件原语)、等待算法、释放算法
1、硬件锁
*获取方法:各P可在锁信号无效时提出总线请求,
获得总线权的P获得同步权(置位锁信号线)
锁结构—锁用总线上信号线表示
*等待算法:各P等待总线控制器的仲裁结果
*释放方法:P复位锁信号线
*特点:灵活性差、锁数量有限,现在已基本不采用
51
转上页
2、简单的软件锁
*获取方法:各P执行硬件原语,成功的P获得同步权
锁 结 构—锁变量(如loca)
硬件原语—测试并设置指令(Test&Set)
*等待算法:
lock:
t&s
bnz
ret
register, loca
lock
//读锁变量loca并置为1
//不成功(原值为1),等待
//成功(原值为0),获取互斥权
*释放算法:
unlock:
st loca, #0
ret
//写0到锁变量loca中
//释放了互斥控制权
52
回下页
回54页
*性能分析:
操作—各P每次尝试执行Test&Set指令,
每条Test&Set指令产生一次BusRdX事务
P1:--I态→M态—I态--------→M态→I态→
P2:----I态--→[M态]…[M态]----→M态→
P3:----I态--→[M态]…[M态]……[M态]→
说明:[M态]表示t&s但不成功(R值=W值=1)的状态
性能—时延小、流量大(与参与P的数量成正比),
可扩放性差(流量变化快)、公正性不确定
*硬件原语的实现方法:选择其中一种方案
方案①--增加原子性的读-改-写总线事务
方案②--使PrRd+PrWr具有“原子性”
(如P或Cache在PrRd与PrWr间不放弃控制权)
53
转上页
转43页
回55页
3、优化的软件锁
(1)后退Test&Set锁
*目标:减少等待期间的流量(执行Test&Set指令的频率)
*获取方法:同Test&Set锁(锁变量+Test&Set指令)
*等待算法:2次Test&Set指令间,插入可变延迟(t=k×ci)
*性能分析:时延增加较快、流量减少,其余指标不变
(2)Test-Test&Set锁
*目标:减少等待期间的流量,但不增加延迟
*获取方法:同Test&Set锁(锁变量+Test&Set指令)
*等待算法:先执行Test指令,锁空闲时才执行Test&Set指令
lock:
test
bnz
t&s
bnz
ret
loca, #0
lock
register, loca
lock
转52页
//读loca并与0比较
//不成功(原值为1),等待
//读锁变量loca并置为1
//不成功(被抢),等待
//成功(原值为0),获取互斥权
54
*性能分析:
操作—各P每次尝试先执行Test指令(发出PrRd操作),
PrRd均会命中Cache,不产生BusRd和BusRdX
P1:--I态→E态→M态→S态…S态→M态→I态→
P2:----I态--------→S态…S态→I态→E态→M态→S态…S态→
P3:----I态--------→S态…S态→I态----------→S态…S态→
性能—时延较小、流量小、可扩放性好、公正性不确定
*三种锁性能比较:Test-Test&Set锁的性能/价格最好
时延
流量
(n个P各获得一次)
可扩 存储
公正性
放性 代价
Test&Set锁
小 大:O(n2×m), m=∑ci
差
好
不保证
后退Test&Set锁
Test-Test&Set锁
大 中:O(n2×i ),i>>n
中 小:O(n2)
中
好
好
好
不保证
不保证
55
转53页
4、高级的软件锁
*目标:①锁被释放时,只有一个P去尝试获得锁;
②锁被释放时,只有一个P发生读扑空
(1)票锁(加号锁)
--实现目标①
*获取方法:各P均持有票号Ti(来自锁、值唯一),
Ti=锁的服务号S时,相应P获得同步权
锁 结 构—锁变量lock、各P的Ti
struct node
{
int T;
int S;
} lock;
//票号
//服务号
硬件原语—取并加一指令(Fetch&increment)
56
回下页
回58页
*等待算法:
Lock( plock, myTicket )
{
myTicket = fetch&increment( plock→P );
while ( myTicket != plock→S );
}
//请求
//等待
*释放算法:
Unlock( plock )
{
plock→S++ ;
}
*性能分析:
时延小、流量较小(锁释放时全部扑空),
可扩展性较好、可保持公正性
57
转上页
回下页
(2)基于数组的锁
--实现目标①和②
*获取方法:各P均持有锁位置Ai(来自锁、地址值唯一),
S[Ai]单元的值有效时,相应P获得同步权
锁 结 构—锁变量lock、各P的Ai
struct node
{
int A;
int* S[MAX];
} lock;
//锁位置,初值=0
//锁位置数组
硬件原语—取并加一指令(Fetch&increment)
*等待算法:
Lock( plock, myAddress )
{
myAddress = fetch&increment( plock→A );
while ( *(plock→S[myAddress]) != 1 );
}
//请求
//等待
58
回下页
转56页
转上页
*释放算法:
Unlock( plock, myAddress )
{
plock→S[myAddress + 1] = 1;
}
*性能:时延小、流量小,其它同票锁;存储代价差O(p)
*几种锁性能比较:
Test-Test&Set锁
加号锁
基于数组的锁
时延
较小
小
小
流量 可扩放性 存储代价 公平性
中
线性
好
不保证
小
最小
线性
常数
较好
差 O(p)
保证
保证
设计策略—
优先考虑流量和时延两个指标;
选择依据是应用特性及机器结构
59
转上页
三、点点事件同步的设计
有软件及硬件2种实现方法
1、软件方法
*获取方法:所取标记值有效时获得同步权
事件标记—普通变量、或信号量
硬件原语—R(释放时W)、或P(释放时V)
*释放方法:置标记值有效
←本P可通过事件
←使其它P可通过
*等待算法:忙等待(普通变量)、阻塞(信号量)
P1
a=f(x); /*set a*/
flag=1;
P2
.
while (flag == 0 );
b=g(a);/*use a*/
60
回下页
2、硬件方法
*获取方法:标记值符合要求时获得同步权
事件标记—满-空位(与存储字关联的硬件位)
硬件原语—特殊的R和W(同时对满-空位操作、原子操作)
*释放方法:W成功(标志位为空)时置满,
R成功(满-空位为满)时置空
*等待算法:特殊R/W操作自动实现等待
P1
a=f(x); /*set a*/
P2
b=g(a);/*use a*/
.
*缺点:局限性大(一对多及写后写不支持)、硬件代价大
61
转上页
四、栅障事件同步的设计
1、集中式软件栅障
*获取方法:FLAG=1时获得同步权
事件标志—标记(FLAG)、计数器(CNT)
硬件原语—锁操作原语
←实现对CNT的互斥修改
*释放方法:CNT=p(参与进程数)时,置FLAG=1
*等待算法:进程到达时CNT+1,然后忙等待或阻塞
简单算法—(下页)
问题:some computation…
BARRIER(bar1, p); //P1被阻塞,P0最后到达(置flag=1)
some computation…
BARRIER(bar1, p); //P0置flag=0,若P1刚醒(死锁)
带感应逆转的算法—(下页)
62
转下页
简单集中式栅障—
带感应逆转的集中式栅障—
BARRIER(bar_name, p)
BARRIER(bar_name, p)
{
{
mysense = !(mysense); //initvalue=0
LOCK(bar_name.lock);
LOCK(bar_name.lock);
if (bar_name.counter == 0)
mycount = bar_name.counter++;
bar_name.flag = 0;
if ( mycount == p ) {
mycount = bar_name.counter++;
UNLOCK(bar_name.lock);
UNLOCK(bar_name.lock);
bar_name.counter = 0;
if ( mycount == p )
bar_name.flag = mysense;
{
}
bar_name.counter = 0;
else {
bar_name.flag = 1;
UNLOCK(bar_name.lock);
}
while ( bar_name.flag != mysense );
else
}
while (bar_name.flag == 0);
}
}
*性能优化: (事件性能取决于锁的性能)
Cache将自身请求BusRd与监听结果比较,地址相同时直
接从总线上取得数据、取消BusRd[已完成]
63
回上页
转42页
2、分布式软件栅障
有软件结合树、并行前序、调度通信事件等方法
*软件合并树的实现:
类似于集中式栅障,用树型标记代替变量标记
struct tree_node {
barrier_helper(struct tree_node *mynode)
int count = 0;
{
int l_sense;
if ( fetch&incment(mynode->count) == k-1 )
struct tree_node *parent;
{ //最后到达的节点
} g_tree[p]; //各元素在不同MEM
if ( mynode->parent != NULL )
barrier_helper(mynode->parent);
private int sense = 1;
mynode->count = 0;
private struct tree_node *myleaf;
mynode->l_sense = !mynode->l_sense;
BARRIER() {
}
barrier_creat(myleaf);
else
barrier_helper(myleaf);
while ( sense !=
sense = !sense; //带感应逆转
mynode->parent->l_sense );
}
}
64
回下页
*软件合并树的性能优化:
性能—取决于树结构特征及锁算法性能;
优化—带自旋的结合树,优化锁算法
3、硬件栅障
*实现:用总线上的“线与”线路实现
*优点:在栅障频率较高的机器中较有用;
*缺点:不利于部分进程参与、进程迁移、同一P多个进程
*栅障事件同步的主流设计:
采用锁和共享变量构造的软件栅障是主流;
同步算法的设计与共享结构(集中/分布)有关
65
转上页

similar documents