> On June 27, 2015, 6:44 p.m., Nilay Vaish wrote: > > src/python/m5/simulate.py, line 335 > > <http://reviews.gem5.org/r/2874/diff/1/?file=46098#file46098line335> > > > > Why do we not need this resume()?
Resume is now called automatically by simualte() if simulate is called on a drained system. We couldn't do this previously since there was no way to accurately query the simulator's drain state. > On June 27, 2015, 6:44 p.m., Nilay Vaish wrote: > > src/sim/drain.hh, line 97 > > <http://reviews.gem5.org/r/2874/diff/1/?file=46102#file46102line97> > > > > Redundant? Yes, but that's intentional since the first line becomes the summary line that's shown in the overview. It's equivalent to a @brief doxygen command. > On June 27, 2015, 6:44 p.m., Nilay Vaish wrote: > > src/sim/drain.cc, line 93 > > <http://reviews.gem5.org/r/2874/diff/1/?file=46103#file46103line93> > > > > missing some words Thank's, I'll sort it out before committing anything. > On June 27, 2015, 6:44 p.m., Nilay Vaish wrote: > > tests/configs/switcheroo.py, line 131 > > <http://reviews.gem5.org/r/2874/diff/1/?file=46104#file46104line131> > > > > I am not very clear of the flow of the code. So again the same > > question, why do we not need this resume() call? Resume will be called automatically on the next simulate() command. > On June 27, 2015, 6:44 p.m., Nilay Vaish wrote: > > src/sim/drain.cc, line 113 > > <http://reviews.gem5.org/r/2874/diff/1/?file=46103#file46103line113> > > > > pre not post. Thanks! - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2874/#review6632 ----------------------------------------------------------- On June 8, 2015, 1:13 p.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2874/ > ----------------------------------------------------------- > > (Updated June 8, 2015, 1:13 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10872:680c6b14b473 > --------------------------- > sim: Decouple draining from the SimObject hierarchy > > Draining is currently done by traversing the SimObject graph and > calling drain()/drainResume() on the SimObjects. This is not ideal > when non-SimObjects (e.g., ports) need draining since this means that > SimObjects owning those objects need to be aware of this. > > This changeset moves the responsibility for finding objects that need > draining from SimObjects and the Python-side of the simulator to the > DrainManager. The DrainManager now maintains a set of all objects that > need draining. To reduce the overhead in classes owning non-SimObjects > that need draining, objects inheriting from Drainable now > automatically register with the DrainManager. If such an object is > destroyed, it is automatically unregistered. This means that drain() > and drainResume() should never be called directly on a Drainable > object. > > While implementing the new functionality, the DrainManager has now > been made thread safe. In practice, this means that it takes a lock > whenever it manipulates the set of Drainable objects since SimObjects > in different threads may create Drainable objects > dynamically. Similarly, the drain counter is now an atomic_uint, which > ensures that it is manipulated correctly when objects signal that they > are done draining. > > A nice side effect of these changes is that it makes the drain state > changes stricter, which the simulation scripts can exploit to avoid > redundant drains. > > > Diffs > ----- > > src/arch/arm/stage2_mmu.hh 282c2a89ace8 > src/arch/arm/stage2_mmu.cc 282c2a89ace8 > src/dev/arm/ufs_device.cc 282c2a89ace8 > src/sim/cxx_manager.cc 282c2a89ace8 > src/sim/drain.hh 282c2a89ace8 > src/sim/drain.cc 282c2a89ace8 > tests/configs/switcheroo.py 282c2a89ace8 > src/mem/xbar.hh 282c2a89ace8 > src/python/m5/simulate.py 282c2a89ace8 > src/python/swig/drain.i 282c2a89ace8 > src/sim/cxx_manager.hh 282c2a89ace8 > src/mem/qport.hh 282c2a89ace8 > src/mem/ruby/system/DMASequencer.cc 282c2a89ace8 > src/mem/ruby/system/RubyPort.hh 282c2a89ace8 > src/mem/ruby/system/RubyPort.cc 282c2a89ace8 > src/mem/dram_ctrl.cc 282c2a89ace8 > src/mem/noncoherent_xbar.hh 282c2a89ace8 > src/mem/noncoherent_xbar.cc 282c2a89ace8 > src/dev/io_device.cc 282c2a89ace8 > src/dev/pcidev.hh 282c2a89ace8 > src/dev/pcidev.cc 282c2a89ace8 > src/mem/cache/base.hh 282c2a89ace8 > src/mem/cache/base.cc 282c2a89ace8 > src/mem/coherent_xbar.hh 282c2a89ace8 > src/mem/coherent_xbar.cc 282c2a89ace8 > src/dev/i8254xGBe.cc 282c2a89ace8 > src/dev/io_device.hh 282c2a89ace8 > src/dev/dma_device.hh 282c2a89ace8 > src/dev/dma_device.cc 282c2a89ace8 > src/dev/copy_engine.hh 282c2a89ace8 > src/dev/copy_engine.cc 282c2a89ace8 > > Diff: http://reviews.gem5.org/r/2874/diff/ > > > Testing > ------- > > Regressions pass. Minor stats difference (due to changes in drain call order) > in one of the pc switcheroo tests. > > > Thanks, > > Andreas Sandberg > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
