On Tue, Apr 24, 2012 at 8:42 AM, Steve Reinhardt <[email protected]> wrote:
> > Also, if a significant fraction of hits are absorbed by the page cache >> > (which I expect is true), then I don't see a benefit from having >> separate >> > state-based caches vs. just having a single cache that has the full >> context >> > as part of the key. Ideally the hash function should do a good job of >> > dealing with the contextual state, and if lookups aren't extremely >> frequent >> > then the overhead of calculating the hash on the larger state shouldn't >> be >> > a big deal. >> >> There are two reasons to not make context part of the key. First, you >> have to keep copying it into your ExtMachInst over and over and over >> even though it's always the same thing. Second, you have to have a more >> complex hash function and/or one that does more work to look up only >> keys that match the context when you're excluding the same possible >> matches over and over and over. If you make the context implicit by what >> cache you pick or the fact that nothing is in there except things that >> are compatible, you can just ignore the context. That makes things >> easier every time you do a lookup which is a lot. >> > > That's why I said "if a significant fraction of hits are absorbed by the > page cache"... if you were doing this on every instruction, the issues you > bring up would matter, but I'm not convinced they matter if you only do it > on a page cache miss. > Or to put it another way, the state-based cache provides two things: (A) avoids the time overhead of having to decode the ExtMachInst and generate a new StaticInst instance, and (B) avoids the memory overhead of having multiple redundant StaticInst instances. When the state-based cache is all you have, these are both important. With the page-based cache in front, I think (B) becomes the primary function and (A) becomes less important. In fact we are probably biasing ourselves by calling it a cache, where it's really more of a memoizer. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
