- Order使用背景
1)除非特别要求,对Normal memory、Device RE的访问,同地址保序即可;
2)对Device nRE\Device nRnE的访问,需要对空间访问保序;
3)CHI中,互联不保证顺序,从相同channel发布的命令不一定按照相同顺序到达HN。
问题:那么CHI如何解决transaction顺序问题?
CHI中提供Comp、CompAck、Order这3种mechanism解决顺序问题,下文分别描述。
- Comp mechanism
- Comp如何传递?
为了解决顺序问题,CHI协议要求Comp满足:“A completion guarantees that the request has reached a PoS or a PoC, where it will be ordered with respect to requests to the same address from any Requester in the system.-P146”。即Completer发布Comp意味着transaction到达下一保序节点,将按照接收transaction的顺序进行处理。接下来,只要保证Completer接收顺序与Requester发布顺序一致即可。
1)在Requester侧,仅当收到Comp之后,再发布同地址/同地址范围的访问;
2)在Completer侧,当transaction到达保序节点(PoS)后,回Comp。(具体见2.4节)
-
- Transaction与Comp
不同transaction的Comp根据访问地址类型,具有不同的含义,具体如下:
1)读访问Noncacheable/Device地址空间时,CompData确保transaction对后续同一地址段(endpoint address range,impdef,from any agent)的transaction可见
2)读访问Cacheable地址空间时,CompData确保transaction对后续同一地址(location,from any agent)的transaction可见
3)Dataless transaction(仅可访问Cacheable地址空间),Comp确保transaction对后续同一地址(location,from any agent)的transaction可见
4)写、Atomic访问Noncacheable/Device nRnE/Device nRE 地址空间时,Comp/CompData确保transaction后续对后续同一地址段(endpoint address range,impdef,from any agent)的transaction可见
5)写、Atomic访问Cacheable/Device RE 地址空间时,Comp/CompData确保transaction对后续同一地址(location,from any agent)的transaction可见
总结规律:若是memory attribute为Device nR*,来自同一agent的去往相同address range的transaction将按照接收顺序进行处理。否则,来自同一agent的相同地址将按照接收顺序进行处理;(备注,读访问不受nR控制?)
-
- Comp什么时候发布?
对于Write:Comp表示该笔传输对其他RN是observable的(收到Comp之后,假如其他RN发布相同地址的读传输,那么读到的一定是该笔传输的数据),因此:
1)对于WriteNoSnp,不需要snoop其他RN,HN收到transaction即可返回Comp (This flow example shows Comp is sent after CompDBIDResp is received from SN-F. However, HN-F is permitted to send Comp anytime after it receives the WriteNoSnp request from RN-F0.-P192)
备注:思考Write的Comp:EWA: Early Write Acknowledgement,表示Write Completion Response是否可以从中间节点提前返回。如果EWA=0,则Write Completion Response必须从Endpoint节点返回后中间节点才能返回。因此上图中如果EWA=0,则HN向RN发送Comp时必须等待收到SN返回的CompDBIDResp. 除*NoSnp、Atomic外的所有传输EWA必须为1.
2)对于WriteUnique,HN必须收到所有snoop resp之后才能返回Comp(因为Comp必须保证别的RN中的cache已经被invalid,之后读到的是新数据);
3)对于CopyBack,因为Comp与DBIDResp必须合并为CompDBIDResp发送,因此必须等到DataBuffer可用后返回;(由于ICN并不保证前后到达的顺序,因此HN在发送CompDBIDResp之前必须保证接收到所有向该RN发送的相同地址的snoop请求对应的响应?)
4)对于Atomic store,需分Snoopable和NonSnoopable分类,Comp与DBIDResp分开或者合并;而其他Atomic由CompData返回,必须分开。
对于Read:Comp通过CompData返回,因此如果有Snoop,一定是在snoop resp之后。
对于Dataless:
1)MakeUnique、CleanUnique必须等snoop resp返回才可汇Comp
2)Evict直接返回:
3)StashOnce*直接返回:
"HN-F can immediately send Comp to RN to acknowledge the Stash request.";-P277:"Permitted to send Comp after receiving the StashOnce request, and before sending any SnpStash or receiving the Snoop response."
4)CMO:本身cache state不改变,别的RN的cache state可能会改变,因此猜测需要Snoop结束再返回,没有找到图片。
-
- Comp mechanism的局限
1)对于读访问,Comp通过DATA通道返回,必须是在获得数据后再返回的,相当于有保序要求的transaction的outstanding深度是1,尤其是需要SN侧取数据的时候,效率很低。
2)对于写访问,WriteUnique需要等待监听结束
- CompAck mechanism
- CompAck如何传递?
若没有CompAck,会怎么样?如下图所示:若无ACK机制。RN1正在进行对某个地址的读取操作(不带Snoop或者snoop已完成),而RN2也在对该地址进行读取操作。对于ICN而言,虽然先收到RN 1的Read,再收到RN 2的Read,但由于CHI不要求总线保序,所以可能Snoop先于Compdata到。这样就会出现对于同一个事情而言,RN1和RN2看到的不同。RN1因为先前已经进行了Snoop,所以认为自己是UC。RN2因为在Snoop的时候看到RN1还是没有该地址的cache,也认为自己是UC。从而产生了不一致。可以归类为,边界条件下,某个状态被全局中各个agent看到的不一致。
而增加CompAck机制后,ICN在收到CompAck之后才能发布对同一地址/地址范围的Snoop访问,从而保证来自一个Requester的transactions与不同Requester的transactions导致的snoop transaction的相对顺序。("The relative ordering of transactions issued by a Requester, and Snoop transactions caused by transactions from different Requesters, is controlled by the use of a Completion Acknowledgment response. This ensures that a Snoop transaction that is ordered after the transaction from the Requester is guaranteed to be received after the transaction response.")
总结CompAck传输规则:
1)在RN侧:收到Comp、CompData之后再回CompAck;
2)在HN侧:在收到CompAck之前,不能发起对同一地址的snoop(对CopyBack transaction,WriteData充当CompAck角色)(HN是从收到transaction还是从返回Comp还是从发snoop到CompAck之间不能发对同一地址的snoop呢?答:HN应当是从发本笔snoop到发CompAck之间不会发对同一地址的snoop;确保RN从收到Comp到回CompAck之间不会收到snoop)。
上述2点确保RN收到Comp和对同一地址snoop的顺序与HN发布Comp和snoop的顺序一致,从而确保对同一地址的transaction通过正确的顺序观察到
-
- CompAck与transaction
仅当ExpCompAck被assert时,Requester才会发送CompAck给HN。使用规则:
1)在RN-F中,除ReadNoSnp/ReadOnce*之外的Read transaction必须assert ExpCompAck;ReadNoSnp/ReadOnce*可按需置位ExpCompAck;MakeUnique/ CleanUnique必须assert;WriteUnique可按需置位;其 他transaction禁止置位ExpCompAck;
2)在RN-I/RN-D中,Read transaction、Write Unique可按需置位ExpCompAck;其他禁止置位ExpCompAck
总结:涉及cache state transition的transaction必须assert ExpCompAck。(疑问:CopyBack传输过程中也涉及cache state transition,为何不需要ExpCompAck?因为CopyBackWdata相当于CompAck。)(CompAck一般用于指示RN内的Cacheline状态已经被改变,并且可以接受后续传输的Snoop请求。)其他ReadNoSnp/ ReadOnce*和WriteUnique不涉及cache state transition转换,但为了配合order使用可以assert?
- Order Mechanism
Comp保序导致效率较低,有无更高效的办法?CHI提供Order 机制,不必等到Comp即可发布同地址/地址范围,只要与下一保序节点(HN)协商好即可。
1)Request Order:保证来自同一agent,去往相同address location的多个transactions的顺序;对于WriteNoSnp,将进一步保证从任意agent发送向同一地址的传输顺序?
2)Endpoint Order:保证来自同一agent,去往相同endpoint address range的多个transaction的顺序;
3)Ordered Write Observation:来自同一agent的,一连串write transactions被别的agents观察到顺序与发布顺序一致(?)
4)Request Accepted:receiver已收到Request,并且不会返回RetryAck
Ordering Requirements:仅ReadNoSnp、ReadOnce*、WriteNoSnp、WriteUnique、Atomic这几类transaction的order必须设为non-zero。为何是这几类支持order呢?上述传输的特点在于从发布transaction的agent没有cache或者不allocate这笔transaction,因此从发布到收到Comp过程中,cacheline状态一直是Invalid态(不变),因此支持通过order域指定order requirement,而不需要Comp。
当相邻传输具有不同的order requirement时,选择较低的order requirement:
-
- Order与transaction
不使用Comp保序之后,HN使用ReadReceipt提前告知RN该读笔操作已经到达下一保序节点;使用DBIDResp告知RN该笔写操作已经到达下一个保序节点。
1)若ReadNoSnp、ReadOnce*中使用Request Order、Endpoint Order,则:
1-1)在Requester侧,收到ReadReceipt后再发布下一个ordered request;
1-2)在Completer侧,发布ReadReceipt意味着:request已经到达下一保序节点,并将按照接收到的顺序进行保序。
2)若WriteNoSnp、Non-snoopable Atomic中使用Request Order、Endpoint Order,则:
2-1)在Requester侧,收到DBIDResp之后才能发布下一个ordered request;
2-2)在Completer侧,发布DBIDResp意味着:request已经到达PoS,并将按照接收到的顺序进行保序。数据buffer已经获得,写请求已经进入PoC并且会保持他被接收的顺序。)
3)若WriteUnique(ExpCompAck=0)、Snoopable Atomic中使用Request Order,则:
3-1)在Requester侧,收到DBIDResp之后才能发布下一个ordered request;
3-2)在Completer侧,发布DBIDResp意味着:Completer将维持来自同一agent,去往同一地址的requests的顺序。(
4)若WriteUnique中使用Ordered Write Observation,则:
4-1)在Requester侧,必须置位ExpCompAck,再收到DBIDResp之后才能发布下一个ordered Request;
4-2)在Completer侧,Completer是一个PoS,发布DBIDResp意味着:本笔request的coherence action的完成不依赖与后续write request(require Odered Write Observation)的coherence action的完成。
4-3)在Completer侧,收到CompAck之后,才能使本笔request被其他Requesters可见
疑问:不同order stream间的ordering dependency如何解除的呢?不同的stream间不需要保序,如何识别不同的stream呢?2.4-P69,详见3.1.1。
( RN需要DBIDResp来决定是否发送下一个需要保序的传输。Completer的一个DBIDResp表明,数据buffer已经获得,PoS将保证此次传输结束的一系列相关性操作,将不依赖于下一个写传输的相关的相关性操作。直到CompAck后写才是可见的。
)
5)CopyBack Request Oder:(for an outstanding CopyBack transaction)
5-1)在Requester侧,收到CompDBIDResp之后才能发布一下个对同一cacheline的request;
5-2)在Requester侧,在收到CompDBIDResp之前,允许发布一笔Atomic transaction(SnoopMe=1)。
-
-
- Streaming Ordered
-
如果Requester发出一连串的WriteUnique transaction,并且希望transactions被观察到的顺序与发布顺序一致,有如下方法:
1)Ordered Write Observation:Comp表征该transaction被观察到,因此Requester可以等收到Comp之后再发送下一个WriteUnique
2)CHI还提供另外更高效的方法:
2-1)Streaming Ordered:(使CompAck与transaction issue顺序一致来保序)
在Requester侧:
a)设置order=Ordered Write Observation(告知HN,本笔transaction的Comp不依赖与后续WriteUnique);
b)设置ExpCompAck=1(在收到本笔Comp以及所有先发ordered WriteUnique的Comp之后,返回CompAck(用以确保先发WriteUnique已完成HN处的操作,其他观察到本笔CompAck的RN肯定已经观察到先发的WriteUnique));
c)收到DBIDResp之后,再发布下一个WriteUnique
在HN侧:
a)HN必须等到CompAck之后,才能Deallocate这笔WriteUnique,才能使这笔transaction对其他observers可见(?)
2-2)Optimized Streaming Ordered:
在上述Straming ordered的基础上,若是上一笔WriteUnique的Target不同,则Requester在发送下一笔ordered WriteUnique之前,不需要等DBIDResp(因此,若是ICN可以remap TgtID,则不可使用本方法)
实现上述两种优化方法时,必须注意避免deadlock和livelock:
1)一种避免技术:
1-1)系统中限制一个Requester使用Optimiazed Streaming Ordered WriteUnique,其他RN可以使用Streaming Ordered WriteUnique
1-2)使用Optimized Streaming Ordered WriteUnique的Requester最好是一个RN-I(比如PCIe)
1-3)若在多个Requester中使用Optimized Streaming Ordered WriteUnique,可以使用WriteDataCancel避免资源相关的deadlock或者livelock
若是EWA使能的、访问Noncacheable\Device的Write transaction,Comp没有确保transaction后续对后续同一地址段(endpoint address range,impdef,from any agent)的transaction可见,还可采取如下技术确保同一地址段transaction保序:
1)order=Endpoint Order,那么后续同样具有order=Endpoint Order的transaction,且在同一endpoint address range的transaction将被保序
2)后续对同一地址Read transaction的CompData可以确保Write transaction对后续同一地址段(endpoint address range,impdef,from any agent)的Write transaction可见
解决不同RN间处理相同地址的一致性问题:
利用CompAck:(前提:互联不保证顺序,从RSP/DATA通道与SREQ通道发布的命令不一定按照发布顺序到达RN,乱序导致一致性出错)
1)在RN侧,仅当完成cache state transition之后再回CompAck;
2)在HN侧,在Comp------CompAck之间,不允许发送相同地址的snoop;
-
- Order与Direct transfer的关系
如下表所示,DCT传输对order字段不做要求,而DMT在有order要求时,必须将ExpCompAck置位,因为:
1)DCT可以使用SnpRespFwd or SnpRespDataFwd确保transaction完成,保证顺序;
2)而使用DMT的transaction:(HN需要知道什么时候释放该笔transaction)
2-1)在no ordering的情况下,若ExpCompAck=0,则可以使用Request Accepted确保SN不会回RetryAck,从而释放资源;
2-2)在no ordering的情况下,若ExpCompAck=1,则即可使用Request Accepted,又可以使用CompAck提前释放资源;
2-3)在ordering的情况下,因为Request Accepted不保证在SN侧的顺序,因此除非ExpCompAck=1,不能发送ordering的DMT transaction
- AXI ordering
- Transaction ordering
Master使用AXID表征ordering requirements:
1)源自不同Master的Transactions间没有order约束,可以任意顺序完成;
2)源自同一Master,AXID不同的transactions间没有order约束,可以任意顺序完成;
3)源自同一Master,一串具有相同ARID的Read transaction必须以Master发布的顺序完成;
4)源自同一Master,一串具有相同AWID的Write transaction必须以Master发布的顺序完成;
5)源自同一Master,具有相同AXID的Read与Write transaction间没有order约束,可以任意顺序完成;若Master对Read与Write有顺序要求,必须等前者返回后再返回后者;
-
- Ordering model定义
对于具有相同AXID的transactions:
1)若target为single peripheral device,必须以发布顺序到达target,不论任何地址;
2)若target为memory,对相同地址、有overlap的地址,必须以发布顺序到达target;
总结下表:同地址一定保序;非同地址时,如果memory type为Device,则同ID保序;如果memory type为Normal,则同ID也可不保序