4.5 Beyond MOESIF

事实上在图4‑10中，O不能直接迁移到I；在图4‑11中O不能直接迁移到I；在图4‑12中，ILO不能直接迁移到ILX；在图4‑13中，O也不能直接迁移到I。在整个Cache Hierarchy的设计中，合理有效解决因为Memory Consistency引发的Race Condition贯彻始终，也引入了过多的所谓“Safe State”，这些Safe State被称为Transient State。我们以图4‑10中简单到不能再简单的I到MM_W的状态迁移说明这些Transient State的作用。

L1 Cache与Sequencer直接相连，当CPU Core进行一次存储器Store操作，将引发一系列复杂的操作，这些操作不仅与采用的Cache Coherence Protocol相关，与采用的Write Policy和使用的Memory Consistency模型也有直接关系。为简化起见，我们选用Weekly Ordered Memory Model，Write Policy为Write-Back Write-Allocate，Coherence Protocol为本节所重点描述的MOESI_CMP_directory。

即便在这种情况之下，我依然会省去更多的细节，忽略绝大多数状态信息和绝大多数总线Transaction，仅书写Store操作中的一种状态转移情况。我希望可以在一个较少的篇幅内完成最基本的说明，给予对这部分内容有兴趣的读者一个入门级别的描述。

在CPUCore中，一个Store操作，引起的结果异常深远，这个Store操作首先到达L1 Cache Controller，之后从一个Stable State进入到一个Safe State，之后穿越当前CMP处理器系统的L2/Directory Cache Controller，到达和这个Store操作相关的其他CMP处理器系统后，再逐级回溯到当前CMP处理器的L1 Cache Controller后，再次进入到另一个Safe State，最终小心翼翼地完成整个操作后进入到最终的Stable State。对于MOESI_CMP_directory，I状态转移到MM_W状态，需要经历IM，OM两个Transient State状态，其过程如图4‑14所示。

 

本次Store操作很幸运，因为在其Miss时，恰好有一个状态位为I的未用Cache Block，这种情况甚至比在Cache中Hit容易处理。首先I状态将迁移到IM状态，在迁移的过程中，完成Cache Block的分配，发送GETX操作，获得当前Cache Block的控制权。

在IM状态时，如果收到Exclusive_Data或者Data后，将迁移到OM状态，在迁移的过程中，将进行数据Merge并写入Cache Block中。为了维护Store的Global View的统一，此时虽然数据已经写入到Cache Block，依然不能通知CPU Core当前Store操作完成，必须要等待CMP处理器系统中所有CPU Core的ACK。一次GETX操作可能会产生多个ACK。当收齐所有ACK后，L1 Cache Controller将Trigger All_acks这个重要的Message。

GEM5Simulator依然简化了IM状态的处理，因为Data/Exclusive_Data和ACK可能是异步的，即便收到了所有的ACK，Data/Exclusive_Data也未必到达，因为ACK与Data的传递可能使用了不同的路径。更为重要的是什么叫All_acks，不同的Protocol采用的方法并不相同。

Intel的MESIF Protocol[96]引入了一个F(Forward)状态。在ccNUMA处理器系统中，可能在多个处理器的Cache中存在相同的数据副本，在这些数据副本中，只有一个Cache Block的状态为F，其他Cache Block的状态为S。

当一个数据请求方读取这个数据副本时，只有状态为F的Cache行，可以将数据副本转发给数据请求方，状态位为S的Cache不能转发数据副本。数据请求方从状态位为F的Cache Block中收到ACK后，即认为收齐了所有ACK。这种方法可以减少Bus Traffic，其他ccNUMA处理器会采用其他方法避免这种Bus Traffic，谈不上是伟大的发明。

在OM状态收到All_acks后，最终迁移到MM_W状态，此时首先通知CPU Core Store操作执行完毕，然后宣布当前Cache Block处于Exclusive状态，之后设置Timeout，在经过一段延时之后，MM_W状态将自动迁移到MM状态。

在MOESI_CMP_directoryProtocol的L1 Cache Controller中与IM和OM类似的Transient State还有SM，IS，SI，OI，MI和II，共计8个；L2 Cache Controller中有50个这样的兄弟；Directory Controller中有15个这样的姐妹。所有这些状态累积在一起形成的FSM不应该用2维方式进行描述，至少需要3维。

我曾试图用2维FSM描述MESI_CMP_directory Protocol，最后发现无法找到尺寸合适的纸张。也许使用PDA(Pushdown Automation)是一个不错的想法，有时间我会进行这方面的尝试。更有人明知我看不懂和Quantum相关的任何内容，依然愚弄我，向我推荐了QFA(Quantum Finite Automata)。

这些SLICC描述可以方便地转换为HTML文件，通过点击鼠标就可发现State之间的迁移，如http://www.cis.upenn.edu/~arraghav/protocols/VI_directory/L1Cache.html所示，只是在状态过多时，使用这样的方法并不方便。

过多的状态增加了Cache CoherenceProtocol的设计复杂度，即便是GEM5的实现也并不容易完全掌握。每次看到莘辛学子们强读GEM5，有种在刀尖上行走的感觉，为他们骄傲的同时祝他们好运。GEM5不是Cache Hierarchy的全部，更不是Cache Coherence Protocol的全部。GEM没有实现最基础的atomic操作，没有实现Memory Barrier，没有连接Cache间的Buffer，也没有更多的Cache层次结构，如L3 Cache，没有太多的实现细节。

GEM5并没有提供有效的Verification策略。而在某种意义上说，Cache Verification的难度甚至超过Design。彻底验证哪怕是最简单的Cache Coherence Protocol也并不是如想象中简单，不仅在于Verification的过程中，会遇到牛毛般匪夷所思的几角旮旯，还在于Verification策略本身的完备。

Design和Verification间存在着密切联系，存在着诸多选择。这使得在一个实际的Cache Hierarchy设计中，取舍愈发艰难。在你面前有太多的选择，无法证明哪一个更为有效，在你面前也没有什么Formal Proof Methods。

在人类的智慧尚没有解决交换舞伴这样平凡的NPHard的前提下，可能最完美最有效的策略只有O(N!)级别的穷举。这些平凡的问题一直等待着不平凡的解读。解决这些问题的人的不朽将远远超越计算机科学这个并不古老的学科。这一切羞辱着天下人的智慧，令世界上最快的K Computer不堪重负。更多的人去依赖没有那么可靠的Quantitative Approach。在这些Approach中，谁去验证了所使用的Models，Theories和hypotheses。

计算机科学在这些不完美中云中漫步。几乎没有人知道准确的方向。有些技巧是没有人传授，因为没有人曾经尝试过。这使得这个星球最顶级的Elite，甘愿穷其一生去做猎物，等待猎人的枪声。没有人欣赏这种方法。更多的是饥饿着的愚钝着的执着。

Stay Hungry，Stay Foolish。