> On May 26, 2016, 2:19 p.m., Andreas Sandberg wrote: > > 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).
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. - Jason ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3475/#review8349 ----------------------------------------------------------- On May 20, 2016, 10:11 p.m., Jason Lowe-Power wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3475/ > ----------------------------------------------------------- > > (Updated May 20, 2016, 10:11 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > 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. > > > Diffs > ----- > > src/sim/simulate.cc fc247b9c42b6 > > Diff: http://reviews.gem5.org/r/3475/diff/ > > > Testing > ------- > > > Thanks, > > Jason Lowe-Power > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
