CHI trans简析--Non-Allocating Read

        此处仅简单分析每个命令的含义，背景，以及可能的状态变化，对于每个trans具体包含的流程，将在下文描述；

    read类型的操作分为两类，allocating read和non-allocating read;

    Non-Allocating read

   ==============================================================

   ReadNoSnp

• 用于RN访问no-snoopable空间，或者HN访问任意空间；
• 此命令的flow, 受order/expcompack控制；
• 发送端的状态可以如下：

    

• 最终的状态如下：

    

• 接收端状态如下：（因为是发送给HN或者SN，所以不涉及每个core的状态跳转）

     

• expected snoop state

   

• cache状态转换图如下：

     

• 访问流程如下：

        a. 可以将comp和data合并返回；

            

        1. 当有保序要求(order != 0)时，HN需要返回readreceipt给RN, 表示该请求已经到达保序点；

        2. (如果是SN返回readreceipt给HN，用来通知HN, SN已经收到该请求，且不会再发送retry ack)

         3. HN将comp响应和data同时返回给RN，即CompData;

        b. data和resp分开返回；

           当存在保序要求时，这种流程不能使用；

           

           此时HN只需要分别将respsepdata/datasepresp分别返回给RN即可；

        c. 数据在SN节点，combined resp;

            

            当存在保序需求且comp_ack==0时，此流程不适用；

          【opt】当有保序需求时，HN收到之后，必须要返回ReadReceipt；

            HN发送readnosnp给SN, 请求数据；

            SN将数据和响应，compdata, 一并返回给RN;(DMT)

        d. 数据在SN, 分开返回；

            

            当存在保序需求且comp_ack==0时，此流程不适用；

            HN返回respsepdata给RN, 发送readnosnpsep给SN,；

            -->readnosnpseq:

                     1. 用在HN发送给SN的请求，请求SN只返回数据；

                     2. 当comp响应和data需要分开返回时，使用该命令；

            --> HN返回给RN RespSepData的时机，可以等到SN返回readreceipt之后，这是可以的，

                 不强求；

         【opt】当compack==0时，HN发送的readnosnp必须要求SN返回readreceipt;

           SN直接将数据返回给RN;

        e. RN返回compack(如果expcompack==1), 返回时刻满足如下要求；

            1. 至少有一个compdata packed返回了；

            2. 在没有order需求时，收到respsepdata;

            3. 在有保序需求时，a, 至少要收到RespSepData和一个DataSepResp;(保证这比trans真的已经执行完了，才能释放所有权)

               ---应该对于seperate的都是这样的；

                                             b. 可以等待readreceipt之后，再发送compack;

           

   ==============================================================

   ReadOnce

• 该命令访问的是snoopable空间，用以获取一份数据，但是该数据不会再当前的RN中缓存；
• 也就是说，只是用一下该地址的数据；无需allocate到本地私有cache；
• 发起操作的初始状态和最终状态如下：

        

        

• 接收命令的core，完成后的状态如下：

     

• 示意流程图如下：

         

• 该命令的完整流程如下；

         

        

          --failed的场景存疑；

   =======================================================================

   ReadOnceCleanInvalid

• 访问的是snoopable的地址空间；获取该地址的数据；
• 建议其他拥有该地址copy的RN，其状态变成invalid, 但是不是强制的；
• 如果dirty的cacheline被invalid了，需要将数据写入主存；
• 当application想要该地址的数据仍然是有效的，但是近期又不使用的时候，可以使用该命令，而不是readonce/readoncemakeinvalid;
• 应用程序用此命令可以提高cache效率，因为其可以减少cache的污染；（因为其主动将近期不使用的cacheline从cache中invalid掉？）
• 此命令不能代替cmo操作，因为它不保证所有的cachline都变成了invalid;
• 由于这个命令会导致cachline的invalid, 因此，当系统中有其他人在使用exclusive访问时，需要小心；
• 发起方可以的状态：

      

• 发起方最终的状态：

     

• 其他core的完成状态：

    

• 对应的snp状态：

    

   ==============================================================

   ReadOnceMakeInvalid

• 访问的是snoopable的地址空间；获取该地址的数据；
• 建议其他拥有该地址copy的RN，其状态变成invalid, 但是不是强制的；
• 如果dirty的cacheline被invalid了，则直接丢弃数据；
• 当application知道后续这个地址的数据不再使用，即不再需要该最新数据之后，可以发送该命令；
• 此种命令在上述场景下，减少了writeback数据到ddr的带宽和时间；
• 此命令的invalid功能可以理解为是一个补丁，不能代替cmo操作，因为当其对应的completion返回的时候，不保证所有的cachline都变成了invalid;
• 由于这个命令会导致cachline的invalid, 因此，当系统中有其他人在使用exclusive访问时，需要小心；
• 此命令必须保证，在返回响应之前，先将该cacheline invalid掉，并且在这个时刻点之后的所有写，都不受此次invalid的影响；
• 发起方的状态/最终状态，完成方的最终状态，对应的snp请求，参考ReadOnceCleanInvalid;

   ==============================================================

   ReadOnce* 和ReadNoSnp可以和DMT/DCT配合使用；