Review Board 2.0.15


cpu: Limit the size of the decode cache

Review Request #1892 - Created June 2, 2013 and updated

Information
Andreas Sandberg
gem5
default
Reviewers
Default
Changeset 9739:245243cf497d
---------------------------
cpu: Limit the size of the decode cache

The decode cache can in some cases grow really large, which can even
prevent some systems from booting. This changeset adds a the ability
to limit the size of the decode cache and randomly prune a fraction of
the cache once it reaches its upper limit. The default behavior on
most architectures is now to allow 4k pages in the cache and prune 50%
once this limit is reached.

   

Issue Summary

4 4 0 0
Description From Last Updated Status
is this appreciably faster than rand() or better yet the Random class in base which is just using a mersenne ... Ali Saidi June 3, 2013, 1:16 p.m. Open
Doxygen please :-) Andreas Hansson June 4, 2013, 1:21 a.m. Open
Is it sensible to even allow 0? Andreas Hansson June 4, 2013, 1:21 a.m. Open
>= rather than == ? Andreas Hansson June 4, 2013, 1:21 a.m. Open
Posted (June 3, 2013, 1:16 p.m.)
looks fine, but if we don't have to embed our own random number generator in the middle of the decode cache code I think that would be best.
src/cpu/decode_cache.hh (Diff revision 1)
 
 
is this appreciably faster than rand() or better yet the Random class in base which is just using a mersenne twister?
  1. I agree that it is a bit (actually very) ugly to have the random number generator there. I didn't want to use the Mersenne twister for performance reasons, but that might have been a premature optimization since this code shouldn't be executed often anyway. I'll replace it with call to the MT implementation unless someone else has a better idea.
  2. I hope this isn't executed often either... should we have a stat that counts the number of times it happens, or print a warning?  The stat is likely to be ignored but would be less intrusive.
    
    Back on topic: if performance is an issue, one option would be to avoid calling the RNG on every page.  For example, if you precalculate that you're going to get rid of 1/N of the pages in the cache, then call the RNG once to pick a number 0 <= s < N, skip s pages, then delete every Nth page after that.  The pseudo-randomness of the order of pages when iterating over the map should provide some protection against pathological behavior.  It might help if N is an odd prime, like 3 or 5.
    
    Popping up a level, if the main driver of this is dealing with ASR, then we might want to consider having a physically indexed page cache, as a sort of "backing store" for the virtually indexed cache(s).  This should prevent the problem from arising in the first place and make disabling ASR unnecessary.  I think this patch should go in regardless, but if we want to make ASR work OK as opposed to just less pathologically, we should think about taking this second step as well.  Also, if we fix the one situation that we know is likely to trigger this replacement, then handling the replacement efficiently becomes even less important.
Posted (June 4, 2013, 1:21 a.m.)



  
src/arch/generic/decode_cache.hh (Diff revision 1)
 
 
Doxygen please :-)
src/cpu/decode_cache.hh (Diff revision 1)
 
 
Is it sensible to even allow 0?
src/cpu/decode_cache.hh (Diff revision 1)
 
 
>= rather than == ?