> On June 23, 2015, 1:35 a.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? > > Steve Reinhardt wrote: > 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.
> can two Ruby components even talk to each other if they're not part of the > same RubySystem? This is the important question. I'm not sure how multiple RubySystem instances will be used. However, it is worth noting that for warm-up and cool-down, Ruby sends memory accesses through the sequencers and RubySystem instance checkpoints will contain traces accessing a particular subset of sequencers. Thus, RubySystem instances in a single simulation should maintain disjoint sets of sequencers. Beyond that, however, it's not clear whether the controllers of separate instances may interact during warm-up and cool-down. This seems likely if the separate RubySystem instances were to represent, for example, separate but coherent sockets in the simulated system. It is definitely possible that separate instances can sink their cool-down flushes to the same memory, and warm-up accesses could access the same memory. Given how complicated this restructuring is and that we're not completely clear how multiple instances may interact, I think it will be worth the effort to maintain these variables as static and use the accessor functions until/unless we find a situation where they need to be changed. Also (a question for Brad maybe?), does anyone know why we don't do RubySystem cool-down during drain(), and why we don't do warm-up during startup() like other gem5 components? - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2902/#review6564 ----------------------------------------------------------- On June 22, 2015, 7: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, 7: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
