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
    








   
  

 









  
 


  

 


















 

  


 


  



   

   
Ali Saidi

   
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?


     





 

  
  
  
  
  
  Show all issues
 




     




  

   

   
    
    

   
  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. 


   
  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.
    
    
    
   
    3. 

   


  


    


   



  

 


  

 

















 



 

  


 


  



   

   
Andreas Hansson

   
Posted  (June 4, 2013, 1:21 a.m.)


  


  


  

   



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/arch/generic/decode_cache.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Doxygen please :-)


     





 

  
  
  
  
  
  Show all issues
 




     




  

   

   
    
    
   


  


    


    

     
     

      

       
        

         
          src/cpu/decode_cache.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Is it sensible to even allow 0?


     





 

  
  
  
  
  
  Show all issues
 




     




  

   

   
    
    
   


  


    


    

     
     

      

       
        

         
          src/cpu/decode_cache.hh
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
>= rather than == ?


     





 

  
  
  
  
  
  Show all issues