----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2874/ -----------------------------------------------------------
(Updated July 6, 2015, 11:43 a.m.) Review request for Default. Repository: gem5 Description (updated) ------- 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 (updated) ----- 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev