On Mon, 3 Aug 2015, Jason Power wrote:
I agree with Joel that this may cause some difficult to track down performance bugs. For instance, if someone has a protocol outside of the mainline, they may not notice this patch and all of the L1 entries will not have MRU set!
I think the problem here is that we rely on the sequencer to update the replacement policy. Controllers should be update replacement policies on their own. That happens for the controllers beyond the first level, no reason to treat the first level controller differently.
If people have code that is not part of gem5, and they update their repo, then it is there responsibility to make sure their own code works. I think many patches that are checked in would break such code and in some cases silently.
Is the only purpose of this patch to increase the performance of Ruby? Can you quantify the performance difference it makes to not call findTagInSet() in the sequencer?
It takes about 50ns per call to findTagInSet (on the machine I use). All those times when the line is found in the first level cache, we would not those extra calls. Overall, a simulation would be about 2% faster.
If the only point is to speed up Ruby IMO, it would be a better option to optimize findTagInSet.
You assume that it can be optimized and that it would yield better results. You can try it, the current patch would still improve over whatever you end up with since the extra calls would still remain in place.
-- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
