----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2841/#review6843 -----------------------------------------------------------
src/mem/ruby/system/Sequencer.cc (line 70) <http://reviews.gem5.org/r/2841/#comment5907> Redundant. Cycles is an unsigned type src/mem/ruby/system/Sequencer.cc (line 703) <http://reviews.gem5.org/r/2841/#comment5908> 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? - Andreas Hansson 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
