----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2874/#review6718 -----------------------------------------------------------
Ship it! Ship It! - Steve Reinhardt On July 6, 2015, 3:43 a.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2874/ > ----------------------------------------------------------- > > (Updated July 6, 2015, 3:43 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10884:1505317a33a8 > --------------------------- > 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 e4f63f1d502d > src/arch/arm/stage2_mmu.cc e4f63f1d502d > src/dev/arm/ufs_device.cc e4f63f1d502d > src/dev/copy_engine.hh e4f63f1d502d > src/dev/copy_engine.cc e4f63f1d502d > src/dev/dma_device.hh e4f63f1d502d > src/dev/dma_device.cc e4f63f1d502d > src/dev/i8254xGBe.cc e4f63f1d502d > src/dev/io_device.hh e4f63f1d502d > src/dev/io_device.cc e4f63f1d502d > src/dev/pcidev.hh e4f63f1d502d > src/dev/pcidev.cc e4f63f1d502d > src/mem/cache/base.hh e4f63f1d502d > src/mem/cache/base.cc e4f63f1d502d > src/mem/coherent_xbar.hh e4f63f1d502d > src/mem/coherent_xbar.cc e4f63f1d502d > src/mem/dram_ctrl.cc e4f63f1d502d > src/mem/noncoherent_xbar.hh e4f63f1d502d > src/mem/noncoherent_xbar.cc e4f63f1d502d > src/mem/qport.hh e4f63f1d502d > src/mem/ruby/system/DMASequencer.cc e4f63f1d502d > src/mem/ruby/system/RubyPort.hh e4f63f1d502d > src/mem/ruby/system/RubyPort.cc e4f63f1d502d > src/mem/xbar.hh e4f63f1d502d > src/python/m5/simulate.py e4f63f1d502d > src/python/swig/drain.i e4f63f1d502d > src/sim/cxx_manager.hh e4f63f1d502d > src/sim/cxx_manager.cc e4f63f1d502d > src/sim/drain.hh e4f63f1d502d > src/sim/drain.cc e4f63f1d502d > tests/configs/switcheroo.py e4f63f1d502d > > 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
