Review Board 2.0.15


Ruby: Change PerfectSwitch's wakeup function

Review Request #328 - Created Dec. 1, 2010 and submitted

Information
Nilay Vaish
gem5
Reviewers
Default 
Currently the wakeup function for the PerfectSwitch contains three loops -

loop on number of virtual networks
  loop on number of incoming links
    loop till all messages for this (link, network) have been routed

With an 8 processor mesh network and Hammer protocol, about 11-12% of the 
was observed to have been spent in this function, which is the highest 
amongst all the functions. It was found that the innermost loop is executed 
about 45 times per invocation of the wakeup function, when each invocation 
of the wakeup function processes just about one message.

The patch tries to do away with the redundant executions of the innermost 
loop. Counters have been added for each virtual network that record the 
number of messages that need to be routed for that virtual network. The 
inner loops are only executed when the number of messages for that particular 
virtual network > 0. This does away with almost 80% of the executions of the 
innermost loop. The function now consumes about 5-6% of the total execution 
time.


   

  


 


 

  

  









  
 


  

 
















 



 

  


 


  



   

   
Brad Beckmann

   
Posted  (Feb. 9, 2011, 1:44 a.m.)


  


  


  

   
Overall, this looks great.  A pretty simple change that offers significant speedup.  I just have one question about the parameters to storeEventInfo.



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/mem/ruby/buffers/MessageBuffer.cc
          

           (Diff revision 2)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Is there a reason why you want to pass the message pointer instead of just the vnet id?




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I would change that. It is a left over from the earlier approach that I 
was thinking of taking, the one in which all messages were queued in the
Perfect Switch as well.
    
    
    
   
    2. 

   


  


    


    

     
     
    

    


     
It seems that you could remove the safe_cast and message pointer dereference if you passed in the vnet id as the first parameter.  Am I missing something?