目录
三、Comments对文献的想法 (强迫自己思考,结合自己的学科)
一、Article:文献出处(方便再次搜索)
(1)作者
- Nicolai Oswald,Vijay Nagarajan(爱丁堡大学)
- Daniel J. Sorin(杜克大学)
(2)文献题目
- HieraGen: Automated Generation of Concurrent,Hierarchical Cache Coherence Protocols
(3)文献时间
- 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA)
(4)引用
- N. Oswald, V. Nagarajan and D. J. Sorin, "HieraGen: Automated Generation of Concurrent, Hierarchical Cache Coherence Protocols," 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), Valencia, Spain, 2020, pp. 888-899, doi: 10.1109/ISCA45697.2020.00077.
二、Data:文献数据(总结归纳,方便理解)
(1)背景介绍
缓存一致性协议是确保在多核处理器中,多个核心对共享数据的视图保持一致的一组规则。随着处理器设计的变化,比如核心数量的增加、不同类型的核心的引入,或者预期通信模式的变化,都需要设计新的缓存一致性协议来适应这些变化。即使新协议与旧协议没有根本的不同,设计和验证新协议也是一个复杂且容易出错的过程。
(2)目的
协议设计的复杂性之一是并发性。如果只考虑原子协议(atomic protocols,通常在教科书中),那么协议设计相对简单。这些原子协议,也称为稳定状态协议(Stable State Protocols, SSPs),只有少数几个稳定的一致性状态(例如MESI),并且有易于理解的状态转换图。然而,现代协议为了尽可能高的性能是高度并发的。许多事务可以同时进行,正是这些并发事务对单个数据块的竞争导致了设计的复杂性。
现代多核处理器中,层次化的Cache协议拓展性更强。然而,层次结构虽然有许多理想的特性,但它也极大地增加了一致性协议设计的复杂性。层次结构中有更多的状态、更多的转换,以及更多可能的并发性。此外,层次结构不同层之间的通信必须保持一致性不变性(coherence invariant)。除了设计复杂性之外,由于状态空间大大增加,层次结构的验证也更具挑战性。
(3)结论
为了规避设计(和验证)层次一致性协议的挑战,作者介绍了HieraGen,它可以用于correct-by-construction的层次协议。用户独立地输入每个层次的SSP,并指定协议连接的点。作者将带有私有缓存的核心称为核心/缓存节点,将带有共址的可选共享缓存的目录称为目录/缓存节点,并使用标准的树术语(根、父、子)来标识层次结构中的节点。因此,更高层次的SSP将只包括根目录/缓存和作为其子节点的核心/缓存节点的规范,此时与平面协议没啥差别(即子节点不可能是一个目录/缓存节点),总的来说:
- 提出了HieraGen,这是第一个根据每个层次的SSP规范来生成完整且并发的层次协议的自动化工具,同时保持安全性并防止死锁。
- 使用HieraGen生成了具有标准MOESI一致性状态的高性能层次协议。
- 使用Murφ模型检查器验证了生成的协议的安全性和无死锁特性。
(4)主要实现手段
4.1 前置知识
4.1.1 ProtoGen
在前面我们提到过ProtoGen,可以根据SSP转换成高度并发的协议设计。设计师只需要考虑SSP,而不需要考虑为了适应并发性所需的瞬态状态和额外的转换。ProtoGen已被证明在创建并发平面目录协议方面是有效的,如图1(a)所示,单个目录(可能与共享缓存共址)直接与所有核心及其私有缓存层次结构通信。
ProtoGenhttps://blog.youkuaiyun.com/qq_46675545/article/details/136092656?spm=1001.2014.3001.5502
因此,ProtoGen只适用于非常有限的系统和协议模型。尽管目录式一致性(directory-like coherence)未来会继续存在,但有几个趋势正在推动行业从平面协议(flat protocols)转向具有层次结构的协议。层次结构是可扩展系统的一种经过时间检验的设计策略,多核处理器设计的核心数量不断增加,它是一种吸引人的方法。层次结构还可以实现更可扩展的一致性协议。
4.1.2 基线系统模型
作者提出了一个具有特定约束的基线系统模型,用于解释HieraGen的工作原理。这个模型包括图1(b)和图1(c)中的两种设计,对于HieraGen来说,这两种设计是等价的。
- 目录/缓存节点:在层次结构中,根目录/缓存连接到主内存。每个目录/缓存节点跟踪其子节点的私有缓存中持有的数据块的一致性状态,以及其共享缓存(如果有的话)持有的数据块。
- 节点类型:为了简洁,作者将四种不同的节点类型分别称为:root(root directory/cache)、cache-H(更高级别协议中的核心/缓存节点)、cache-L(更低级别协议中的核心/缓存节点)和dir/cache(中间目录/缓存节点)。
- SSPs:更高级别和更低级别的SSP分别称为SSP-H和SSP-L,其中“更高级别”指的是更接近根的层次,“更低级别”指的是离根更远的层次。
- 假设的约束:作者假设了五个约束条件,这些条件在第七部分中会有所放宽:
- 层次结构只有两级。
- 目录是inclusive和full-map的,且只读块的驱逐不是静默的(silent),即每个目录对其子节点的一致性状态是完全了解的。
- 每个SSP都是平面目录协议。
- 共享缓存是inclusive的。
- 跨层次结构的通信是严格的父子关系,即节点不能直接与其他层次的节点通信。同一层次内的通信是通用的。
- 术语:本文使用Sorin等人的术语,包括一致性状态(例如,表示数据块在I和S状态之间瞬态状态的IS)和一致性请求(例如,GetShared或GetS)。
- tips:文中提到的inclusive是指高层次的cache(L2)包含了其子层次缓存(L1)的所有数据块;fullmap指目录能跟踪所有可能的缓存块的状态,即每个缓存块都有一个对应的条目。一个inclusive和fullmap的目录能够提供对整个缓存层次结构中数据块状态的完整视图。
4.2 实现流程
4.2.1 HieraGen工作流程
输入:HieraGen的输入是每个层次的SSP,这些SSP描述了缓存控制器和目录控制器在原子系统模型中的行为,即在任何给定时间只有一个事务在进行。
输出:HieraGen的输出是所有不同的核心/缓存节点和目录/缓存节点的有限状态机(FSM)。这些FSM描述了在实际并发环境中,这些节点如何响应各种一致性请求和状态转换。
工作流程:HieraGen的工作流程分为两个主要步骤:
- 第一步:将平面SSP转换为原子层次协议。它将每个层次的SSP整合成一个原子层次协议,这个协议能够处理层次结构中的一致性问题。
- 第二步:将原子层次协议转换为并发层次协议。在这一步中,HieraGen将原子层次协议扩展为能够处理实际并发事务的协议。
协议组合的哲学:HieraGen的设计哲学是在最通用的方式下执行协议组合,而不特定于任何具体的协议或状态。这意味着HieraGen不会修改输入的稳定状态协议(SSPs)。
关键思想:HieraGen将其他层次的一致性动作封装在一个一致性事务中,以确保全局范围内强制执行单一写者多读(SWMR)和数据值不变性。则:
- 在完成来自特定层次的读请求之前,确保其他层次没有写者(如果有写者,首先将其降级)。
- 在完成写请求之前,确保其他层次没有读者或写者(如果有,首先使它们失效)。
如何执行:如图3表明,来自低层次缓存(cache-H)的一致性请求在低层次无法完全满足时,HieraGen如何确保高层次准备好以完成请求。图4指出了,则指的是如何将高层次无法完成的缓存请求放到低层次执行?
低层次请求在高层次如何处理?
- HieraGen通过处理低层次的SSP(SSP-L),能够确定低层次一致性请求的访问类型(是读还是写)。
- 然后,利用高层次的SSP(SSP-H),HieraGen使高层次的缓存(cache-H)生成相同访问类型的高层次请求。
- 由于SSP-H在高层次强制执行SWMR,当cache-H从高层次目录(dir-H)接收到响应时,可以推断出高层次已经准备好在低层次执行访问。
- HieraGen恢复低层次的一致性事务,即dir-L对cache-L的响应,从而在全局范围内完成低层次的一致性事务,同时强制执行SWMR。
总结来说,HieraGen通过封装和协调不同层次的一致性动作,确保在层次结构中正确地维护数据一致性。它通过分析低层次的SSP来确定请求类型,并利用高层次的SSP来生成相应的高层次请求,从而在全局范围内维护SWMR和数据值不变性。
高层次请求在低层次如何处理?
-
请求转发(①②):一个来自高层次缓存(cache-H1)的一致性请求被高层次目录(dir-H)转发到另一个高层次缓存(cache-H2)。如果这个请求在高层次无法完全满足,HieraGen需要介入。
-
封装低层次协议动作:HieraGen在高层次事务中封装低层次协议动作,以确保低层次准备好以完成高层次的请求。这类似于之前的场景,HieraGen利用高层次的稳定状态协议(SSP-H)来确定高层次请求的访问类型。
-
创建代理缓存控制器(③):由于cache-H逻辑上属于高层次不能对dir-L发起读写请求,HieraGen不能直接使用这些实体来发起低层次的请求。因此,HieraGen从一个低层次的SSP(SSP-L)中克隆一个缓存控制器,称为代理缓存(proxy-cache),并将其集成到中间的目录/缓存节点(dir/cache)中。
-
代理缓存的作用(④-⑥):HieraGen使代理缓存向低层次目录(dir-L)发起一个一致性请求,该目录然后将请求转发到低层次的一个或多个缓存。当代理缓存接收到响应时,可以推断出低层次已经准备好在高层次执行访问。
-
完成请求(⑦⑧):代理缓存随后将数据块逐出到高层次缓存(cache-H),允许cache-H响应请求者,从而在全球范围内强制执行SWMR。
总结来说,HieraGen通过创建一个代理缓存控制器,并将其集成到中间目录/缓存节点中,来处理那些在高层次无法完全满足的请求。代理缓存负责与低层次目录通信,确保低层次准备好响应高层次的请求。一旦低层次准备好,代理缓存将数据逐出到高层次缓存,完成整个请求过程,同时维护了SWMR的一致性不变性。
实例分析
在分层缓存体系结构中,假设层次结构的两个级别都使用典型的MSI协议。需要目录缓存(dir/cache)同时提供其两个主要功能(目录管理和缓存一致性),以三种事务类型为例:
① 事务类型:SSP-L(低层级共享状态协议)中的加载(loads)操作,涉及到SSP-H(高层级共享状态协议)。
-
初始状态:在开始时,有一个数据块(block)位于一个cache-H(高层级缓存)中,并且处于M状态(即Modified状态)。
-
GetS-L请求:低层级缓存(cache-L)发起了一个GetS-L请求到目录缓存(dir/cache)。这个请求在SSP-L中对应于一个读取操作,因为最终的事务状态只允许读取而不允许写入。
-
HieraGen的作用:HieraGen是一个逻辑生成器,它通过处理SSP-L中的GetS-L请求,推断出这是一个读取操作。同样,它也可以通过处理SSP-H中的信息,推断出如果cache-H需要获取读取权限,它会发出GetS-H请求。
-
请求匹配:HieraGen将cache-L的GetS-L请求与cache-H的GetS-H请求进行匹配。因为cache-L的GetS-L提供了读取权限,所以它促使目录缓存向dir-H(目录缓存的根节点)发出GetS-H请求,以便cache-H可以获得读取权限。
-
目录缓存的处理:dir-H和SSP-H的其余部分对这个类型的一致性请求按照通常的方式处理。在这个例子中,dir-H将GetS-H请求转发给拥有数据的cache-H,然后该cache-H用数据响应dir-H。
-
数据传输:目录缓存用从cache-H获取的数据填充自己的cache-H部分,然后响应最初发起GetS-L请求的cache-L。这个响应与在平面SSP-L中对原始GetS-L请求做出的响应相同。
② 事务类型:SSP-H中的load / store操作,涉及到SSP-L。整个流程如下图6所示,其中绿色实线表示高层协议和dir/cache之间的交互,蓝色实线表示低层协议和dir/cache的交互,红色虚线表示dir/cache内部之间的交互。这种事务的出现可能是:cache-L独占一个状态为S的数据块(其它缓存没有该数据块),cache-H就会如图6所示发出请求。
- GetM-H和Inv-H请求:通常, cache-H会向自己的dir-H发出请求,dir-H执行两个操作:将请求(以Invalidation-H的形式)转发给dir/cache,并通知请求的cache-H预期会收到多少个确认(Acknowledgments)
- HieraGen作用:通过处理SSP-H,可以判断Invalidation-H对应于写操作(而不是读操作),并且需要dir/cache模拟对可写数据请求的处理。代理缓存是cache-L控制器的一个克隆,集成在dir/cache中,用于封装一致性事务,但不执行加载或存储操作。通过处理SSP-L,知道cache-L在需要获取写权限时会发出哪种一致性请求,即GetM-L。然后,代理缓存向dir-L发出GetM-L请求(内部请求)。dir-L随后向状态为S的cache-L发送Invalidation-L,并转换到状态M(因为它现在视代理缓存的该块为状态M)。这个GetM-L事务在状态为S的cache-L向代理缓存发送Invalidation-Ack-L后完成,确保所有cache-L节点在与发起原始GetM-H请求的cache-H相关的一致性状态(Invalid)上是适当的。
- 数据传输:一旦GetM-L事务完成,代理缓存立即将缓存块驱逐到dir/cache,导致dir-L的状态从M变为I。然后,dir/cache向根节点响应SSP-H的适当响应(在例子中是Invalidation-Ack-H)。如果cache-L节点是所有者,响应将包括数据。

③ 事务类型:目录缓存的驱逐。为了维护目录的inclusive性质,这个过程涉及到从所有低层级缓存节点中移除块的副本,然后更新目录缓存的状态,并向根节点报告这一变化。
- 当需要从目录缓存中驱逐一个块时,首先通过代理缓存发出GetM-L请求。这个请求会导致代理缓存持有SSP-L中该块的唯一副本。如果cache-L是该块的所有者,它会在块被失效时将数据发送给代理缓存。
- 一旦代理缓存持有了块的唯一副本,它就会将该块驱逐到目录缓存中。这时,目录缓存(dir/cache)会持有该块的副本。
- 为了完成驱逐操作,目录缓存向根节点发出PutM-H请求。这个请求是SSP-H中用于处理拥有块的一致性请求,它通知根节点该块已经被移除。
当从dir/cache中驱逐一个块之前,必须确保所有cache-L中拥有该块的副本也被移除。HieraGen再次使用代理缓存来实现这一目的,并利用其处理SSP-L的能力来发现哪种SSP-L一致性请求会从所有cache-L节点中使块失效。因此,代理缓存发出GetM-L,结果是代理缓存持有SSP-L中块的唯一副本。(如果cache-L是所有者,在失效时,它会将其数据发送给代理缓存。)然后,代理缓存将块驱逐到dir/cache。一旦唯一的副本在dir/cache中,dir/cache向根节点发出PutM-H,这是SSP-H中用于驱逐拥有块的一致性请求。
如何组合cache-H、dir-L和proxy-cache-L以产生中间的目录/缓存控制器?核心是从一个输入控制器中获取“code”,然后将它们拼接在一起。
① 控制器的符号表示法:
- “Accesses”指的是一组访问操作,包括load、store和evict。
- “States”、“Requests”和“Fwd-requests”分别指的是与控制器相关联的一组状态、请求和转发请求。例如,cache-L.States指的是与低层级缓存控制器相关联的一组稳定状态。
- “send-request”、“send-fwd-request”、“await-response”、“update-state”和“send-response”是指向执行其名称所指示操作的代码的变量。
② 缓存控制器:
SSP中的缓存控制器组件为每个稳定状态指定了在每次访问和每个传入的转发请求上发生的事情。这可以这样指定:
- 对于所有访问操作和状态,缓存控制器会发送请求、等待响应和更新状态。
- 对于所有转发请求和状态,缓存控制器会更新状态并发送响应。
例如,对于一个低层级MSI缓存控制器,cache-L.send-request(store,I)指向发送GetM到dir-L的代码;cache-L.await-response(store,I)指向等待数据的代码;cache.update-state(store,I)指向将状态从I更改为M的代码。有些代码指针可能指向空操作,例如,对于状态为M的数据块的存储操作,不需要发送任何消息,也不需要进行状态更新。
③ 目录控制器:
SSP中的目录控制器组件为每个稳定状态指定了在传入请求上发生的事情。这可以这样指定:对于所有请求和状态,目录控制器会发送转发请求、等待响应和更新状态。
③ 生成dir/cache控制器:
dir/cache控制器结合了dir-L和两个缓存控制器(cache-H和cache-L)。这个复合控制器既是目录也是缓存,需要为dir-L和cache-H状态的笛卡尔积指定以下两种情况下的行为:
- 来自cache-L的传入请求(incoming request,图3)。
- 对于dir-L的每个请求和dir-L与cache-H状态的组合,首先计算导致请求的访问操作。
- 然后,控制器向更高级别发送相同访问类型的请求(如果需要)。
- 最后,控制器响应原始请求。
- 来自dir-H的传入转发请求(incoming fowarded request,图4)。
- 对于cache-H的每个转发请求和dir-L与cache-H状态的组合,首先通过解析SSP-H计算导致转发请求的访问操作。
- 实际上,代理缓存是dir/cache控制器内物理集成的单个临时缓存行(和状态)。我猜想,由于cache-H没法直接访问dir-L,所以构造了一个代理缓存行来模拟cache-L,这样这个代理缓存就可以向dir-L发出请求,dir-L在针对请求做出相应。但是实际上,代理缓存的请求和相应不需要实际发送,而是让dir-L计算它可能会发送的请求,并针对这个虚拟请求做出响应,然后再传给cache-H。
- 理论上,代理缓存在收到响应后更新其状态,并将块驱逐到dir-L,但这个驱逐也是虚拟的,所以实际上没有消息被发送。dir-L计算出对应于evict访问的请求,并让dir-L对这个请求做出反应。
- 最后,cache-H响应来自更高级别的传入转发请求。
注意:传入请求通常是直接由缓存节点发起,用于满足本地处理器的需求;而传入转发请求则是在缓存一致性协议中,由目录控制器或其他缓存节点发起,用于处理跨缓存层级的数据一致性问题。
④ 关于兼容性问题
在MESI协议中,存在静默权限升级问题,即只读状态E静默地升级到可读写状态M。这种升级可能会导致层次协议违反SWMR。举个例子,以MESI(SSP-L)和MSI(SSP-H)为例,如果所有缓存最初都处于无效状态(I),当一个cache-L执行load并未命中时,它会向dir/cache发出GetS-L请求。dir/cache随后向根目录发出GetS-H请求,根目录以只读权限和数据响应dir/cache,由于没有其他共享者,dir/cache以独占权限响应cache-L,那么cache-L可以静默地从E状态转换到M状态并写入块。同时,任何cache-H可以向根目录发出GetS-H请求并获得只读访问(因为根目录不知道有数据块从E->M,以为都是读操作)。这种情况下,层次协议违反了SWMR,即同时存在读写。
HieraGen解决这个兼容性问题有2种做法:
- 直观解决方案:在cache-L load miss时,让dir/cache保守地发出GetM-H请求,使该块获得的最大权限(可读写访问),而不是原始请求的GetS-H请求(只读访问)。这个解决方案确保了安全性,但如果cache-L实际上没有写入块,会导致不必要的SSP-H无效化,从而影响性能。
- 高性能解决方案:为了避免不必要的无效化,HieraGen在生成dir/cache时添加逻辑,以检测其从SSP-H接收的权限(S=只读)与其dir-L本应授予cache-L请求者的权限(E=可静默升级为可读写)之间的不匹配。在这种情况下,代理缓存发出与接收权限相对应的请求,即代理缓存发出GetS-L。这样,代理缓存模仿外部cache-H的可能行为。代理缓存的GetS-L在cache-L的GetS-L之前序列化,使dir-L暂时处于E状态,然后它将授予请求的cache-L S(而不是E)权限。一旦dir/cache响应了cache-L,dir-L变为S状态,代理缓存逐出该块。
进一步的优化:如果SSP-H和SSP-L都有E状态,并且所有块最初都处于I状态,当cache-L请求读取块时,dir/cache首先以E状态获取块(由于SSP-H),然后以E状态提供给请求的cache-L(由于SSP-L)。现在,cache-L可以静默地升级到M并修改块,而不需要通知dir/cache。这导致了另一个需要解决的E状态不匹配问题。我们希望dir/cache的cache-H变为M状态,以便与cache-L之前执行的存储操作兼容。此外,我们希望在不修改SSP-H的情况下完成这一点,这符合HieraGen的设计哲学。
解决E状态的不匹配:当cache-L将块逐出到dir/cache时(应该是指到cache-H),逐出消息的类型(PutE-L或PutM-L)揭示了cache-L中执行的访问类型。在这种情况下,PutM-L揭示了发生了写操作。因此,现在必须有cache-H的写操作以更新其数据(即dir/cache中更新过来的数据层层传递到达cache-H)。但由于cache-H在E状态,需要一个写操作时,无需向dir-H发出请求;根据SSP-H的规定,它可以静默地变为M状态。
在步骤1,HieraGen为cache-L、dir/cache、cache-H和根目录生成了一个原子分层协议。在步骤2中,利用层次协议的树结构和序列化点,为层次协议添加并发性,允许多个事务同时进行。
层次协议的序列化点:在层次协议中,与平面协议(flat protocol)不同,可能存在多个序列化点,这取决于块的当前所有者的协议级别。例如,如果一个请求完全在SSP-L内得到满足,它在dir/cache处被序列化;如果一个来自cache-H的请求或一个不能在SSP-L内得到满足的来自cache-L的请求,则在根目录处被序列化。
利用树结构的不变性:尽管存在两个序列化点(或更多,如果有更多的层次),层次结构提供了一个不变性:任何两个竞争的一致性事务都会恰好在其中一个序列化点上进行序列化。这使得HieraGen可以利用ProtoGen来提取并发性。
竞争事务的处理:HieraGen生成的原子协议全局强制执行SWMR,这意味着任何块只能有一个所有者。因此,任何两个竞争的事务都会尝试通过遍历一个或多个目录节点的路径来到达这个唯一的所有者。树结构保证了在两条路径上会有恰好一个共同的目录节点。这个共同的目录节点作为唯一的序列化点,使得事务在到达这个节点时可以推断出它是否赢得了访问权限。
由于存在这样的序列化点,HieraGen可以使用ProtoGen来执行第二步,即在层次协议中添加并发性。ProtoGen通过在目录节点上序列化竞争事务,生成高度并发且非阻塞的控制器动作,同时保持一致性。
4.2.4 其他系统模型
在4.1.2 中介绍了基线系统模型,为了简化模型,作者在基线系统模型中施加了五个设计约束,包括:层次结构的级别、目录的类型、SSP的类型、共享缓存的特性以及跨层次通信的规则。现在,作者将探讨放宽这些约束的影响。
A. 更深层次的层次结构(Deeper Hierarchies):
- 组合(Step 1):层次结构的深度不影响HieraGen组合SSPs的方式。这是因为在SSP组合的每个点上,都有一个结构化的接口,即单个dir/cache节点,它为其父节点提供缓存功能,为其子节点提供目录功能。HieraGen使用这个接口确保在完成一个层次的一致性请求之前,其他层次都处于允许完成该请求的状态,而不违反全局SWMR。此外,HieraGen不允许跨层次通信,除非通过这个结构化接口。
- 并发性(Step 2):更深层次的层次结构对HieraGen引入并发性的方式也没有影响。无论层次结构的深度如何,任何两个竞争的事务都会在恰好一个节点上序列化。这使得可以使用ProtoGen来注入并发性。
B. 目录知识的不完整性(Incomplete Directory Knowledge):
- 目录可能对其子节点的一致性状态有不完整或过时的知识,这可能是由于目录使用不完整的数据结构、子缓存被允许静默地逐出只读块,或者目录不是包容性的。幸运的是,这个问题不影响HieraGen,因为它在输入的SSPs中已经处理了(这个不太理解,意思是说这种情况不会出现?因为在SSP中指明了吗)。
C. 其他SSP协议类型:
- 虽然假设每个SSP都是平面目录协议,但实际上有一些灵活性。关键是协议必须有一个单一的结构,可以作为层次之间接口。目录协议自然具有这种结构。然而,监听协议也可以被视为具有“空目录”的目录协议。只要互连网络在“目录”和其每个子节点之间提供点对点的顺序,这种协议就会提供广播监听。
D. 非包容性的共享缓存(Non-Inclusive Shared Caches):
- 到目前为止,假设共享缓存是Inclusive 的,但有些系统提供 exclusive 或 non-Inclusive(即既不是严格Inclusive 也不是exclusive )的共享缓存。HieraGen目前仅限于Inclusive 共享缓存。这种限制的根本原因是HieraGen的设计理念,即允许用户完全独立地指定SSPs,并且在组合它们时不修改SSPs。为了解决非Inclusive 共享缓存的问题,未来的工作将探索放宽SSPs之间严格分离的可能性。
E. 跨层次通信(Communication Across Levels):
- 假设层次结构是树形的,通信是严格的层次结构。节点只能与其父节点、子节点或兄弟节点通信。例如,cache-L不能直接与根目录或cache-H通信。这个假设使得我们可以清晰地推理SSPs的组合,并且对HieraGen当前的设计和实现至关重要。
(5)实验结果
评估目标:评估HieraGen在生成并发层次协议方面的有效性,并通过与输入SSPs的复杂性进行比较,来展示HieraGen在设计自动化方面的优势。
基准测试(Benchmarks):使用flat input SSPs和层次结构的描述作为基准测试。这些SSPs包括典型的MSI、MESI、MOSI和MOESI协议,但不包含并发性。在表一中,我们给出了flat input ssp的复杂性。复杂性很难精确地量化,但对于一个flat的一致性协议,state的数量和reachable state/event pairs(即transitions)是合理的代理。
设计复杂性(Design Complexity):HieraGen的目标是克服手动设计层次协议的复杂性。通过提供一对输入SSPs(SSP-L和SSP-H),研究HieraGen产生的并发层次协议的复杂性。首先研究第一步的结果,即原子层次协议的复杂性。在表II中,展示了七种不同层次协议的可量化复杂性结果。每行比较了给定层次协议的输入SSPs的dir-L和cache-H与自动生成的dir/cache的复杂性。这些结果表明,dir-L和cache-H似乎比表一中的更复杂,这是因为HieraGen包括了瞬态。在第一步引入的复杂性可能相当大,且在不同协议之间变化很大。例如,MSI/MI层次中的dir/cache与组成部分的总和相比,只多了一个状态,但可达转换数量大约翻倍。而在MOESI/MOESI层次中,dir/cache有59个状态和368个转换,远多于其组成部分(21个状态和78个转换)。
当HieraGen向协议添加并发性时,检查步骤2中引入的额外复杂性。为每个协议运行两次HieraGen,一次是设置了输入标志以生成一个停止协议,另一次是未设置该标志。表三显示了HieraGen最终输出的可量化复杂性;该表复制了表II的结果,以便于可视化比较。一个奇怪的结果是,并发协议中的节点通常比相应的原子协议具有近似相同或更少的状态。这种现象是因为,即使协议的复杂性增加了,HieraGen也经常可以发现如何合并等价的状态。
并发性引入的复杂性(Concurrent Complexity):在第二步中,当HieraGen为协议添加并发性时,研究引入的额外复杂性。发现并发协议中的节点通常具有与原子协议相同或更少的状态。这是因为HieraGen能够发现并合并等价的状态。
正确性验证(Verification of Correctness):为了确认HieraGen生成的协议在逻辑上是正确的并且在实际运行中不违反一致性且不会死锁,对每个协议进行了三次验证。首先使用Murφ模型检查器对第一步产生的原子层次协议进行完整的形式化验证。其次,对HieraGen生成的并发层次协议进行验证。最后,为了增加可信度,添加了一个额外的cache-L节点,并使用Murφ的哈希压缩功能来扩展验证。
实验结果:HieraGen在不到10秒的时间内正确生成了本节中的每个协议。并且,HieraGen能够自动且几乎瞬间地生成正确构建的协议。
(6)问题记录
① 本文在融合不同层次的cache协议时,一个核心的设计是dir/cache,即:将dir-L和cache-H融合,并创造性的提出了proxy-cache-L。proxy的出现是为了让cache-H能够成功访问cache-L,proxy本质上是cache-L的一个缓存行的副本,通过proxy充当中介,cache-H可以间接访问cache-L的数据块。但有个问题我一直没看明白的是——数据块的驱逐,文中一直提到在完成请求后,要将访问的数据块驱逐到dir/cache中,是指将访问的数据块从proxy中放到cache-H中,并作废cache-L中的数据块?(如果这是一个写操作的话,只能有一个cache能保留该块)在“解决E状态的不匹配”的问题时,提到cache-L将块逐出到dir/cache,是指将cache-L中的该数据块放到dir/cache中吗?
② 另一个需要求证的问题是,文中时常提到根据SSP-H或者SSP-L能知道这个请求是写操作还是读操作,所以这个SSP到底是指啥呢?或许知道PutE/PutM和GetS/GetM能指明访问是读or写?
- PutM请求,当它拥有某个数据块的修改副本(即数据块处于修改状态M)并且需要将这个副本写回到上一级缓存或主内存时(读写操作)。
- PutE请求,当它拥有某个数据块的独占副本(即数据块处于独占状态E)并且需要将这个副本传递给请求访问该数据块的其他缓存时(写操作)。
- GetM请求,当它需要将一个数据块从只读状态(如共享状态S)升级到可读写状态(如修改状态M)时(读写操作)。
- GetS请求,当它希望获取对某个数据块的共享访问权限时(读操作)。
③ 有一点没明白,在步骤二中,为啥ProtoGen可以作为HieraGen的一个基础步骤来实现两个竞争事务的序列化呢?ProtoGen确实可以序列化给定块的多个并发事务,但它的序列化点一直是固定且确定的,因为ProtoGen处理的是flat protocol。HieraGen也要处理多个事务并发时如何进行序列化的问题,如论文中所说树结构可以让多个任务通过节点遍历最终追溯到某一个序列化点,但这始终和直接利用ProtoGen存在差别。或许是通过遍历确定好序列化点(即某一个目录节点)后,再在事务到达该目录节点是决定哪个事务获得处理权限。
(7)其他积累
在结构化层次cache一致性协议中,可考虑的方向:
- 结构化层次协议的框架
- 一致性协议的自动化设计
- 为可验证性而设计的分层协议
三、Comments对文献的想法 (强迫自己思考,结合自己的学科)
本文提出的HieraGen可以成功地将atomic flat ssp组成成一个高度并发的层次协议。生成的协议是可验证的正确的,并且避免了手动设计所需的大量设计和验证工作,可以生成具有数十个状态和数百个transition的缓存控制器和目录控制器。
现在我有带你迷惑的是,前面明明说的是多个层次化协议的组合,再得到一个高并发的层次化协议,但conclusion又说的是flat spp得到层次协议。这篇论文创新度还行,但是遣词造句方面我反正得多读几遍才能理解。后面可以考虑看一下一致性协议的验证是如何进行的,结合形式化方法再进一步了解。
四、Why:为什么看这篇文献 (方便再次搜索)
了解课题背景:
- 了解层次化cache一致性协议的实现
五、Summary:文献方向归纳 (方便分类管理)
Hierarchical Cache Coherence Protocols
- design automation
- concurrency
- model checker