----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2875/#review6629 -----------------------------------------------------------
Ship it! Ship It! - Nilay Vaish On June 21, 2015, 8:02 p.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2875/ > ----------------------------------------------------------- > > (Updated June 21, 2015, 8:02 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10885:c52ced3af33b > --------------------------- > sim: Refactor and simplify the drain API > > The drain() call currently passes around a DrainManager pointer, which > is now completely pointless since there is only ever one global > DrainManager in the system. It also contains vestiges from the time > when SimObjects had to keep track of their child objects that needed > draining. > > This changeset moves all of the DrainState handling to the Drainable > base class and changes the drain() and drainResume() calls to reflect > this. Particularly, the drain() call has been updated to take no > parameters (the DrainManager argument isn't needed) and return a > DrainState instead of an unsigned integer (there is no point returning > anything other than 0 or 1 any more). Drainable objects should return > either DrainState::Draining (equivalent to returning 1 in the old > system) if they need more time to drain or DrainState::Drained > (equivalent to returning 0 in the old system) if they are already in a > consistent state. Returning DrainState::Running is considered an > error. > > Drain done signalling is now done through the signalDrainDone() method > in the Drainable class instead of using the DrainManager directly. The > new call checks if the state of the object is DrainState::Draining > before notifying the drain manager. This means that it is safe to call > signalDrainDone() without first checking if the simulator has > requested draining. The intention here is to reduce the code needed to > implement draining in simple objects. > > > Diffs > ----- > > src/arch/arm/table_walker.hh e4f63f1d502d > src/arch/arm/table_walker.cc e4f63f1d502d > src/arch/arm/tlb.hh e4f63f1d502d > src/cpu/kvm/base.hh e4f63f1d502d > src/cpu/kvm/base.cc e4f63f1d502d > src/cpu/minor/cpu.hh e4f63f1d502d > src/cpu/minor/cpu.cc e4f63f1d502d > src/cpu/minor/pipeline.hh e4f63f1d502d > src/cpu/minor/pipeline.cc e4f63f1d502d > src/cpu/o3/cpu.hh e4f63f1d502d > src/cpu/o3/cpu.cc e4f63f1d502d > src/cpu/simple/atomic.hh e4f63f1d502d > src/cpu/simple/atomic.cc e4f63f1d502d > src/cpu/simple/timing.hh e4f63f1d502d > src/cpu/simple/timing.cc e4f63f1d502d > src/cpu/testers/traffic_gen/traffic_gen.hh e4f63f1d502d > src/cpu/testers/traffic_gen/traffic_gen.cc e4f63f1d502d > src/dev/arm/flash_device.hh e4f63f1d502d > src/dev/arm/flash_device.cc e4f63f1d502d > src/dev/arm/ufs_device.hh 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.hh e4f63f1d502d > src/dev/i8254xGBe.cc e4f63f1d502d > src/dev/ide_disk.cc e4f63f1d502d > src/dev/ns_gige.hh e4f63f1d502d > src/dev/ns_gige.cc e4f63f1d502d > src/dev/sinic.hh e4f63f1d502d > src/dev/sinic.cc e4f63f1d502d > src/mem/cache/mshr_queue.hh e4f63f1d502d > src/mem/cache/mshr_queue.cc e4f63f1d502d > src/mem/dram_ctrl.hh e4f63f1d502d > src/mem/dram_ctrl.cc e4f63f1d502d > src/mem/dramsim2.hh e4f63f1d502d > src/mem/dramsim2.cc e4f63f1d502d > src/mem/packet_queue.hh e4f63f1d502d > src/mem/packet_queue.cc e4f63f1d502d > src/mem/ruby/structures/RubyMemoryControl.hh e4f63f1d502d > src/mem/ruby/structures/RubyMemoryControl.cc e4f63f1d502d > src/mem/ruby/system/DMASequencer.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/ruby/system/Sequencer.cc e4f63f1d502d > src/mem/simple_mem.hh e4f63f1d502d > src/mem/simple_mem.cc e4f63f1d502d > src/mem/xbar.hh e4f63f1d502d > src/mem/xbar.cc e4f63f1d502d > src/sim/drain.hh e4f63f1d502d > src/sim/drain.cc e4f63f1d502d > src/sim/process.hh e4f63f1d502d > src/sim/process.cc e4f63f1d502d > src/sim/sim_object.hh e4f63f1d502d > src/sim/sim_object.cc e4f63f1d502d > src/sim/system.hh e4f63f1d502d > src/sim/system.cc e4f63f1d502d > > Diff: http://reviews.gem5.org/r/2875/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
