Brad and I will be having a discussion today on how to resolve this issue.
--
Nilay
On Tue, 23 Nov 2010, Steve Reinhardt wrote:
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
