> On June 22, 2015, 6:35 p.m., Joel Hestness wrote: > > src/mem/ruby/system/Sequencer.cc, line 529 > > <http://reviews.gem5.org/r/2902/diff/1/?file=46572#file46572line529> > > > > Currently, all references to warm-up and cool-down variables should use > > the static accessors, RubySystem::getWarmupEnabled() and > > RubySystem::getCooldownEnabled(), respectively. > > > > I stand by my observation that warm-up and cool-down are > > simulation-wide operations, not per-RubySystem instance. This is because > > controller activity from one RubySystem instance may affect controllers in > > other RubySystems (e.g. cache flushing during cool-down). m_warmup_enabled > > and m_cooldown_enabled should remain static variables of the RubySystem > > class. > > > > Is there something getting in the way of leaving these static?
I'm confused---can two Ruby components even talk to each other if they're not part of the same RubySystem? I haven't looked at the code closely, so I don't have a strong opinion, but I'll say that: 1. It does seem unlikely that you would be doing warmup or cooldown in one RubySystem but not in another, but given that we've never run a simulation with two RubySystem objects before, it also seems premature to declare that we'd never want to do that. 2. If making the warmup/cooldown flags static actually eliminates the need for having a RubySystem pointer in a significant number of objects, then it might be worthwhile, but if that pointer needs to be in those objects for other reasons anyway, then it doesn't seem like much of a win. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2902/#review6564 ----------------------------------------------------------- On June 22, 2015, 12:19 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2902/ > ----------------------------------------------------------- > > (Updated June 22, 2015, 12:19 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10877:2e6e2150542a > --------------------------- > ruby: removes g_system_ptr and replaces with object based references > > > Diffs > ----- > > src/mem/protocol/RubySlicc_Types.sm > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/SConscript ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/common/Global.hh ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/common/Global.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/network/MessageBuffer.hh > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/network/MessageBuffer.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/network/simple/SimpleNetwork.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/network/simple/Switch.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/network/simple/Throttle.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/profiler/AddressProfiler.hh > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/profiler/AddressProfiler.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/profiler/Profiler.hh ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/profiler/Profiler.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/slicc_interface/AbstractController.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/BankedArray.hh > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/BankedArray.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/Cache.py ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/CacheMemory.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/RubyMemoryControl.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/SConscript ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/structures/WireBuffer.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/DMASequencer.hh > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/DMASequencer.cc > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/RubyPort.hh ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/RubyPort.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/Sequencer.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/Sequencer.py ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/System.hh ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/System.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/slicc/symbols/StateMachine.py > ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/slicc/symbols/Type.py ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/python/swig/pyobject.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > > Diff: http://reviews.gem5.org/r/2902/diff/ > > > Testing > ------- > > > Thanks, > > Brandon Potter > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
