还有点疑问：

把cacheline推到LLC，cpu访问的latency会更大。一般L1 cache hit的话只要几个cycle， L2 需要十几个，到bus上的LLC会更大。感觉更多是为了解决一个公平性的问题？ 还有需要考虑到一个系统多cluster，每个cluster里面多cpu的情况。同cluster的多个cpu访问lock的话，push到L3 cache感觉更好点。不过貌似硬件没法知道改cache是cluster内部还是外部的cpu在用，因为write后都给invalidate掉了。

硬件实现上貌似bus protocol需要升级。对于普通的lock实现来讲，cpu1释放lock的时候，会invalidate掉其他cpu里面的cache，同时会唤醒其他cpu对该lock address进行访问。在这个专利的要求下， 从其他cpu发起的访问需要被hold住，不仅等cpu1的write完成，还需要等到其被push到LLC，而且在bus coherency logic里面要把存放该cpu 的状态给清掉。

transactional memory的情况，前面提到可能有多个cache line数据。根据其历史访问状态（记录在cache tag ram里面？）有的需要push到LLC，有的不需要。 比如transaction 1的block 对address A，B进行操作， transaction 2 block对A和C。 其他cpu在什么时候可以访问，感觉bus实现复杂了很多。


【 在 MaLing 的大作中提到: 】
: "cpu1提交 transactional memory成功后，主动把cache给flush到LLC，方便下一个cpu来访问？"
: Ling: 是
:
: ....................
--
FROM 101.88.10.*