----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4696 -----------------------------------------------------------
src/sim/eventq.hh <http://reviews.gem5.org/r/1667/#comment4442> Would it be better to call this curEventQueue? This is a pretty ugly name. (I know, probably my fault originally.) src/sim/eventq.hh <http://reviews.gem5.org/r/1667/#comment4440> This looks like an irrelevant whitespace-only change. src/sim/eventq.hh <http://reviews.gem5.org/r/1667/#comment4441> I realize (looking back) that this is my change, but it seems like it needs at least a comment. I'm also surprised that the second unserialize isn't marked virtual. I suppose the right answer ties in with our long-term discussion of checkpointing (see below), but in the short term it would be nice to at least have a comment here. Or is there one somewhere else that I missed? src/sim/eventq.hh <http://reviews.gem5.org/r/1667/#comment4438> Missing "event" in comment. src/sim/serialize.cc <http://reviews.gem5.org/r/1667/#comment4439> It seems odd that we're generating N identically named "MainEventQueue" sections. I expect that it works fine (since they're processed in order on both ends), but *if* we're going to stick with this model, then we should put indices on the names (perhaps except for queue 0, for backward compatibility). That said, we should also have a discussion about whether this is the right model at all. In the near term, we should probably stick with it because I don't want to hold things up, but in the long run, do we really want the number of threads to be baked into the checkpoint? I'd argue that checkpoints should be taken at a higher level such that the number of threads can be varied between a save and a restore. - Steve Reinhardt On Aug. 20, 2013, 9:20 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Aug. 20, 2013, 9:20 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9841:b42a2994b221 > --------------------------- > 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 43d22d746e7a > src/base/barrier.hh PRE-CREATION > src/cpu/base.cc 43d22d746e7a > src/dev/etherlink.cc 43d22d746e7a > src/python/m5/SimObject.py 43d22d746e7a > src/python/m5/event.py 43d22d746e7a > src/python/m5/main.py 43d22d746e7a > src/python/m5/simulate.py 43d22d746e7a > src/python/swig/event.i 43d22d746e7a > src/sim/Root.py 43d22d746e7a > src/sim/SConscript 43d22d746e7a > src/sim/core.hh 43d22d746e7a > src/sim/debug.cc 43d22d746e7a > src/sim/eventq.hh 43d22d746e7a > src/sim/eventq.cc 43d22d746e7a > src/sim/eventq_impl.hh 43d22d746e7a > src/sim/global_event.hh PRE-CREATION > src/sim/global_event.cc PRE-CREATION > src/sim/root.cc 43d22d746e7a > src/sim/serialize.hh 43d22d746e7a > src/sim/serialize.cc 43d22d746e7a > src/sim/sim_events.hh 43d22d746e7a > src/sim/sim_events.cc 43d22d746e7a > src/sim/sim_exit.hh 43d22d746e7a > src/sim/sim_object.cc 43d22d746e7a > src/sim/simulate.hh 43d22d746e7a > src/sim/simulate.cc 43d22d746e7a > src/sim/stat_control.cc 43d22d746e7a > > 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
