Review Board 2.0.15


ruby: Replace queueMemory calls with MessageBuffer enqueues in GPU protocols

Review Request #3355 - Created Feb. 29, 2016 and updated

Information
Matthew Poremba
gem5
default
Reviewers
Default 
Changeset 11355:02756e2f2053
---------------------------
ruby: Replace queueMemory calls with MessageBuffer enqueues in GPU protocols

Calls to queueMemoryRead and queueMemoryWrite are removed in a previous
patch. This patch replaces these calls with enqueues to a MessageBuffer
which provides flow control to the directories. This modifies all GPU
protocols to use the new interface.

   

  


 


 

  

  









  
 


  

 
















 



 

  


 


  



   

   
Jason Lowe-Power

   
Posted  (Feb. 29, 2016, 11:02 a.m.)


  


  


  

   
What is it about the GPU protocols that's different from all the other protocols? 


Also, does this mean that you can't use the DRAMCtrl with with GPU protocols anymore? I personally always use the DRAMCtrl instead of the Ruby memory controller. In fact, I think it's default for all other protocols.



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Nothing particularly special, but the current queueMemory calls really have no way to fail and simply push requests into the QueuedMasterPort. With GPU applications I found it to be much easier to find cases that fill the port's internal packet_queue and trigger an assertion if the size grows larger than 100 packets. If these function calls are being removed, this change will also need to be applied to the CPU protocols, but i'd like to get a consensus between you, Joel, and others before spending time updating those.
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    I see. 
    

    The problem I have with this patch (as I understand it) is that it seems to undo changeset 10524:fff17530cef6 (ruby: interface with classic memory controller). See http://reviews.gem5.org/r/2422/
    

    I think it's a step in the wrong direction to go back to requiring the Ruby memory controller. The classic DRAM model is much more flexible than Ruby's (and more accurate as well, I believe).
    

    I could be off base here, though. Am I misunderstanding what this patch does?
    
    
    
   
    3. 


   
  3. 
    
    
     
    
      
     
    
     
    This change wouldn't go back to the Ruby memory controller. It is dependent on another patch (http://reviews.gem5.org/r/3356/) which handles consuming the MessageBuffers and sending them to the DRAMCtrl port. The benefit here is to avoid infinite buffering that occurs when calling the queueMemoryRead/Write functions. Since they return void, there is really no way for the method to fail and provide back-pressure so they must push the request to the port. This path leverages enqueue in SLICC, which is converted to C++ code that first calls areNSlotsAvailable and allows Ruby to return a ResourceStall if this returns false to prevent infinite buffering. I should have put in the review that this patch also depends on http://reviews.gem5.org/r/3356/ , particularly the changes in AbstractController and StateMachine.py
    

    Joel has a similar solution in http://reviews.gem5.org/r/3332/ and http://reviews.gem5.org/r/3331/. Our approach are slightly different since we are trying to avoid using retries and NACKs as flow control.
    
    
    
   
    4. 


   
  4. 
    
    
     
    
      
     
    
     
    Thanks for the clarification! I expected I was missing something. I'll take a look at http://reviews.gem5.org/r/3356/ soon and update this review as well.
    
    
    
   
    5.