On Sept. 21, 2013, 3:39 p.m., Nilay Vaish wrote: > > Some minor comments. One thing I'd like to understand is how this affects > > the ongoing work to run gem5 together with SystemC (as an SC_THREAD in > > fact). Does this patch make the SC integration impossible? If so I think > > there are good reasons to discuss the trade-off in a lot more depth before > > pushing this.
Why would it make integration with SC impossible? It might require some changes, but in theory if you were using SC then you could just run it in thread. Either way, being pragmatic this works now. It allows us to thread multiple-systems, and lets us make the KVMCPU work with an MP system. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4727 ----------------------------------------------------------- On Sept. 20, 2013, 8:59 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2013, 8:59 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9882:39ca1efd64fb > --------------------------- > sim: simulate with multiple event queues > This patch extends the patch Steve posted on the reviewboard (846). The patch > updated with all the changes that have taken place over last 15 months. Code > has been added so as actually carry out a quantum-based parallel simulation. > > The patch was tested in two different configurations: > 1. ruby_network_test.py: in this simulation L1 cache controllers receive > requests from the cpu. The requests are replied to immediately without > any communication taking place with any other level. > 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server > system which are connected by an ethernet link. > > We still lack the ability to communicate using message buffers or ports. But > other things like simulation start and end, synchronizing after every quantum > seem to be working. > > > Diffs > ----- > > src/SConscript 5fad1d2eb314 > src/base/barrier.hh PRE-CREATION > src/cpu/base.cc 5fad1d2eb314 > src/dev/etherlink.cc 5fad1d2eb314 > src/python/m5/SimObject.py 5fad1d2eb314 > src/python/m5/event.py 5fad1d2eb314 > src/python/m5/main.py 5fad1d2eb314 > src/python/m5/simulate.py 5fad1d2eb314 > src/python/swig/event.i 5fad1d2eb314 > src/sim/Root.py 5fad1d2eb314 > src/sim/SConscript 5fad1d2eb314 > src/sim/core.hh 5fad1d2eb314 > src/sim/debug.cc 5fad1d2eb314 > src/sim/eventq.hh 5fad1d2eb314 > src/sim/eventq.cc 5fad1d2eb314 > src/sim/eventq_impl.hh 5fad1d2eb314 > src/sim/global_event.hh PRE-CREATION > src/sim/global_event.cc PRE-CREATION > src/sim/root.cc 5fad1d2eb314 > src/sim/serialize.hh 5fad1d2eb314 > src/sim/serialize.cc 5fad1d2eb314 > src/sim/sim_events.hh 5fad1d2eb314 > src/sim/sim_events.cc 5fad1d2eb314 > src/sim/sim_exit.hh 5fad1d2eb314 > src/sim/sim_object.cc 5fad1d2eb314 > src/sim/simulate.hh 5fad1d2eb314 > src/sim/simulate.cc 5fad1d2eb314 > src/sim/stat_control.cc 5fad1d2eb314 > > Diff: http://reviews.gem5.org/r/1667/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
