> On Feb. 10, 2013, 8:19 p.m., Steve Reinhardt wrote: > > src/sim/eventq.hh, line 198 > > <http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line198> > > > > I would really like to solve this problem without adding yet another > > field to the Event structure. I think that all the common cases could be > > solved definitively just by appropriate selection of priorities. I'm > > surprised that less common cases (if any) don't sort themselves out > > naturally just because all the threads would be inserting the global events > > in the same program order. > > Nilay Vaish wrote: > Let me give an example here. Suppose two threads need to insert global > exit > events in the next quantum at the same cycle. They will insert the event > in > their own queues and the async queue of the other thread. When each > thread > will make insertions from its async queue to its actual event queue, the > event ordering would be opposite in the two threads, unless there is a > global > order between the events. When the threads execute these events, they end > up > on different barriers and the simulation is not able to proceed ahead. > > I think we do need a total order amongst global events. If you have some > other > solution in mind, I am ready to consider it. > > Steve Reinhardt wrote: > I understand the need for a consistent order to prevent deadlocks. > Thanks for the example of how this arises in practice. > > Given that global events must always be scheduled at least one quantum > away, what if we require that global events (including all their local > subevents) must be scheduled when we're in "serial mode" during the quantum > synchronization? There could be an additional locked async queue for global > events that gets drained at the quantum synchronization, and all global > events go through this queue. How does that sound?
Here is a different strategy. Have a global mutex that a thread needs to hold inorder to schedule global events. Add the global events to the asyncq first. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4013 ----------------------------------------------------------- On Feb. 10, 2013, 1:44 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Feb. 10, 2013, 1:44 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9497:484d33f78ef4 > --------------------------- > 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/cpu/base.cc ff4b1bde5f60 > src/dev/etherlink.cc ff4b1bde5f60 > src/python/m5/SimObject.py ff4b1bde5f60 > src/python/m5/event.py ff4b1bde5f60 > src/python/m5/main.py ff4b1bde5f60 > src/python/swig/core.i ff4b1bde5f60 > src/python/swig/event.i ff4b1bde5f60 > src/sim/SConscript ff4b1bde5f60 > src/sim/core.hh ff4b1bde5f60 > src/sim/debug.cc ff4b1bde5f60 > src/sim/eventq.hh ff4b1bde5f60 > src/sim/eventq.cc ff4b1bde5f60 > src/sim/eventq_impl.hh ff4b1bde5f60 > src/sim/global_event.hh PRE-CREATION > src/sim/global_event.cc PRE-CREATION > src/sim/serialize.cc ff4b1bde5f60 > src/sim/sim_events.hh ff4b1bde5f60 > src/sim/sim_events.cc ff4b1bde5f60 > src/sim/sim_exit.hh ff4b1bde5f60 > src/sim/sim_object.cc ff4b1bde5f60 > src/sim/simulate.hh ff4b1bde5f60 > src/sim/simulate.cc ff4b1bde5f60 > src/sim/stat_control.cc ff4b1bde5f60 > > 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
