Hi Marius, ReadEx is read exclusive, you're right.
The reason we get away with not having an entry for transitionTable[Invalid][ReadEx].onRequest is that the protocol does not handle the general case of multilevel coherent caches. Effectively for now you're limited to either a single level of caches or a set of coherent L1 caches backed by a shared L2. In the latter case the L2 should use 'uni' coherence and not the full coherence protocol. Since we don't support configurations where there's a coherent cache behind another coherent cache, the protocol will never see ReadEx as a request.
We have plans to remedy this but haven't had the time to implement it. Our current plan is to allow all the caches to snoop on a single shared bus (much like in most modern systems, both the L1 and L2 snoop together on external traffic). The problem could also be solved by enforcing inclusion but that's less common in industry these days (AFAIK... I'm not exactly sure what Core 2 Duo does, for example).
In the longer run we would really like a more general network-based (not just bus-based) coherence infrastructure; a big part of the v2 memory system rewrite was to make that more feasible. We haven't really started on actually implementing that though. There's been talk of integrating Wisconsin's GEMS code but no action as of yet. Contributions are welcome :-).
Steve Marius Grannæs wrote:
Hello, I think there is a missing state transition in mem/cache/coherence/coherence_protocol.cc , namely trasitionTable[Invalid][ReadEx].onRequest Am I correct in assuming that it should be (ReadEx)? Also, is ReadEx an exclusive read, or am I missing something?
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
