----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2874/#review6695 -----------------------------------------------------------
Ship it! Ship It! - Nilay Vaish On June 8, 2015, 12: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, 12: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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
