Steve Reinhardt: > 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).
I can probably get away with inclusion. Do you have support for this in M5? I couldn't find any references to this in BaseCache.py, or do I need to hack the c++ code? > 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 :-). Yes, this would be very interesting. Also, I think that multi-level cache coherence will become important to more people than just me in the future. I haven't had the time to really look at v2 yet, but I hope to move my work to it when it gets out of beta. -- Marius Grannæs _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
