> On July 28, 2015, 9:12 p.m., Andreas Hansson wrote: > > src/mem/ruby/system/Sequencer.cc, line 70 > > <http://reviews.gem5.org/r/2841/diff/2/?file=48512#file48512line70> > > > > Redundant. Cycles is an unsigned type
This asserts >0, rather than >=0, which would be guaranteed by the unsigned type. > On July 28, 2015, 9:12 p.m., Andreas Hansson wrote: > > src/mem/ruby/system/Sequencer.cc, line 703 > > <http://reviews.gem5.org/r/2841/diff/2/?file=48512#file48512line703> > > > > response? > > > > No need to change anything, but surely there is more to it than > > response. > > > > In the classic cache we have forward latency, lookup latency, response > > latency. How does Ruby differentiate the latency from request -> response, > > request -> request, snoop request -> snoop response, snoop request -> snoop > > request, and response -> response, snoop response -> snoop response? > > Perhaps something to think more about? Yes, there's a lot more to moving cache latencies into Ruby protocol controllers and different protocols may have different requirements. Not sure we need to be verbose in this comment, but hopefully we can continue the migration soon. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2841/#review6843 ----------------------------------------------------------- On July 25, 2015, 5:30 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2841/ > ----------------------------------------------------------- > > (Updated July 25, 2015, 5:30 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10933:cf3a413d2c38 > --------------------------- > ruby: Remove the RubyCache/CacheMemory latency > > The RubyCache (CacheMemory) latency parameter is only used for top-level > caches > instantiated for Ruby coherence protocols. However, the top-level cache hit > latency is assessed by the Sequencer as accesses flow through to the cache > hierarchy. Further, protocol state machines should be enforcing these cache > hit > latencies, but RubyCaches do not expose their latency to any existng state > machines through the SLICC/C++ interface. Thus, the RubyCache latency > parameter > is superfluous for all caches. This is confusing for users. > > As a step toward pushing L0/L1 cache hit latency into the top-level cache > controllers, move their latencies out of the RubyCache declarations and over > to > their Sequencers. Eventually, these Sequencer parameters should be exposed as > parameters to the top-level cache controllers, which should assess the > latency. > NOTE: Assessing these latencies in the cache controllers will require > modifying > each to eliminate instantaneous Ruby hit callbacks in transitions that finish > accesses, which is likely a large undertaking. > > > Diffs > ----- > > configs/ruby/MESI_Three_Level.py cafae9abd4e4 > configs/ruby/MESI_Two_Level.py cafae9abd4e4 > configs/ruby/MI_example.py cafae9abd4e4 > configs/ruby/MOESI_CMP_directory.py cafae9abd4e4 > configs/ruby/MOESI_CMP_token.py cafae9abd4e4 > src/mem/ruby/structures/CacheMemory.hh cafae9abd4e4 > src/mem/ruby/structures/CacheMemory.cc cafae9abd4e4 > src/mem/ruby/system/Sequencer.hh cafae9abd4e4 > src/mem/ruby/system/Sequencer.cc cafae9abd4e4 > src/mem/ruby/system/Sequencer.py cafae9abd4e4 > configs/ruby/MOESI_hammer.py cafae9abd4e4 > configs/ruby/Network_test.py cafae9abd4e4 > src/mem/ruby/structures/Cache.py cafae9abd4e4 > > Diff: http://reviews.gem5.org/r/2841/diff/ > > > Testing > ------- > > Small tests with all different protocols to verify appropriate performance > changes. > > Please consider this patch as a substitute for http://reviews.gem5.org/r/2796/ > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
