Thanks for tracking that down; that confirms my suspicions. I think the long-term answer is that the system needs to be reworked to avoid having to do multiple tag lookups for a single access; I don't know if that's just an API change or if that's something that needs to be folded into SLICCer. (BTW, what is the status of SLICCer? Is anyone working on it, or likely to work on it again?)
In the short term, it's possible that some of the overhead can be avoided by building a "software cache" into isTagPresent(), by storing the last address looked up along with a pointer to the block, then just checking on each call to see if we're looking up the same address as last time and if so just returning the same pointer before resorting to the hash table. I hope that doesn't lead to any coherence problems with the block changing out from under this cached copy... if so, perhaps an additional block check is required on hits. Steve On Tue, Nov 16, 2010 at 3:17 PM, Nilay Vaish <[email protected]> wrote: > I was looking at the MOESI hammer protocol. I think Steve's observation > that extra tag lookups are going on in the cache is correct. In particular I > noticed that in the getState() and setState() functions, first > isTagPresent(address) is called and on the basis of the result (which is > true or false), getCacheEntry(address) is called. Surprisingly, the > getCacheEntry() function calls the isTagPresent() function again. These > calls are in the file src/mem/protocol/MOESI_hammer-cache.sm > > Thanks > Nilay > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
