> On Sept. 16, 2013, 11:34 p.m., Steve Reinhardt wrote: > > src/sim/eventq.hh, line 70 > > <http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line70> > > > > Would it be better to call this curEventQueue? This is a pretty ugly > > name. (I know, probably my fault originally.)
Remained as _curEventQueue. > On Sept. 16, 2013, 11:34 p.m., Steve Reinhardt wrote: > > src/sim/eventq.hh, line 347 > > <http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line347> > > > > This looks like an irrelevant whitespace-only change. Rolled back. > On Sept. 16, 2013, 11:34 p.m., Steve Reinhardt wrote: > > src/sim/eventq.hh, line 498 > > <http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line498> > > > > Missing "event" in comment. Fixed. > On Sept. 16, 2013, 11:34 p.m., Steve Reinhardt wrote: > > src/sim/serialize.cc, line 462 > > <http://reviews.gem5.org/r/1667/diff/8/?file=37175#file37175line462> > > > > 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. The naming has been kept as is to avoid having to update the previously created checkpoints. We can add the queue index after we have worked out the details of checkpointing when running with multiple queues. As of now, we can just say that one should create checkpoints only in a single queue regime. > On Sept. 16, 2013, 11:34 p.m., Steve Reinhardt wrote: > > src/sim/eventq.hh, line 411 > > <http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line411> > > > > 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? Added a comment. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4696 ----------------------------------------------------------- On Aug. 20, 2013, 4:20 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Aug. 20, 2013, 4:20 p.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
