> On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.hh, line 472 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line472> > > > > Nothing urgent, but is a list really the best choice here?
If you are suggesting that we use a deque, I think there is no difference in time and space complexities. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.hh, line 493 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line493> > > > > assert async_queue_mutex == NULL This function is being removed. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.hh, line 489 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line489> > > > > initialize async_queue_mutex to NULL The call EventQueue("") allocates space for the mutex. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.cc, line 50 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37730#file37730line50> > > > > Is the notion of the quantum described somewhere? A smallish comment existed in the .hh file. It has been expanded now. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq.cc, line 464 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37730#file37730line464> > > > > Why not in the initializer list? > > Done. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/global_event.hh, line 2 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37732#file37732line2> > > > > Been cooking for a long time? :-) > > Steve Reinhardt wrote: > Indeed it has... though it was December 2011 when I made the first pass > on this code, so it hasn't been *quite* two full years yet. That's why I'm > (1) grateful to Nilay for finishing the job and (2) anxious to see this > finally get committed. Steve originally posted patch in 2011. I have added / updated copyright holders for most of the files that are being touched by the patch. > On Sept. 21, 2013, 3:39 p.m., Andreas Hansson wrote: > > src/sim/eventq_impl.hh, line 55 > > <http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55> > > > > is it worth checking inParallelMode first? > > > > As a side not, do we know what the performance impact is when not > > running in parallel mode? (perhaps this has been resolved already) I'll run the regression tests and report the execution time differences soon. - Nilay ----------------------------------------------------------- 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
