Review Board 2.0.15


sim: Fix fork for multithreaded simulations

Review Request #3475 - Created May 20, 2016 and updated

Information
Jason Lowe-Power
gem5
default
Reviewers
Default 
Changeset 11483:d7066cc30459
---------------------------
sim: Fix fork for multithreaded simulations

Previously, when forking, the thread states were inconsistent.
Now, after a fork, we re-create all the needed threads.
This allows you to run in *single-threaded* mode after a fork.
There would need to be a way to migrate the threads to conintue
in threaded mode.

   

  


 


 

  

  






 
 
Issue Summary

 

  

   
    
    1
   
   
    
    0
   
   
    
    1
   
   
    
    0
   
  

  

   

    
    
   

   

    
    
   

  

 

 

  

   
    

     Description
     From
     Last Updated
     Status
    

   
   







    

















   
  

 









  
 


  

 


















 

  


 


  




   
Ship it!



   

   
Joel Hestness

   
Posted  (May 23, 2016, 9:48 a.m.)


  


  


  

   
LGTM. Minor note below.



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/sim/simulate.cc
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
It might be safer to use an initial PID that will definitely not be a valid PID (e.g. -1) rather than 0, which is a valid PID (just unlikely that it would ever be used for a user process).


     





 

  
  
  
  
  
  Show all issues
 




     




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Good point, I'll make this change. Although, I would hope that gem5 isn't the init process ;).
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    There has been talk of merging gem5 into systemd. However, I just boot directly to gem5 and skip the kernel altogether.
    
    
    
   
    3. 

   


  


    


   



  

 


  

 

















 



 

  


 


  



   

   
Andreas Sandberg

   
Posted  (May 26, 2016, 7:19 a.m.)


  


  


  

   
Thanks for looking into this!

Forking a multi-threaded simulation is very scary. If I remember my POSIX right, the behaviour after a fork of a multi-threaded program is undefined (IIRC, you are supposed to call exec without passing go and collecting $200). This is one of the reasons I didn't handle it when I originally implemented forking (and I didn't need it at the time).

I would suggest that you instead make sure that all threads are joined before forking (e.g., by joining them after draining).



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Let me explain my use case and then maybe you can explain in a little more detail how I should change this patch.
    

    I'm running gem5 with the KVM CPU with multiple host threads for performance (and so KVM works...). At some point, I want to fork gem5 to do detailed simulation. So a new gem5 instance starts that will be single threaded. At the same time, I want the original gem5 process (the KVM one) to continue executing to the next detailed sample point. And so on.
    

    The problem I ran into was much of the thread state hung around after the fork. I tried to remove all the threads after the fork, but that didn't work since fork doesn't copy the other threads' state. The simplest solution I found was this patch.
    

    I'm not sure if joining the threads in the original gem5 process will work with my use case. I would have to spin up all the KVM threads again after the fork, right? I highly doubt that this would be straightforward... but I could be wrong.
    
    
    
   
    2.