> On May 29, 2015, 12:52 a.m., Brad Beckmann wrote: > > Have you looked at the implications of cache hit latencies greater than 1? > > In our experience, a hit latency greater than 1 causes consistent pipeline > > bubbles and significant performance degradation. The O3 model does not > > perform well and you do not achieve real system behavior. > > > > Since you went through the effort to remove the latency parameter, let's > > completely remove it rather than add new L1 icache and dcache hit latency > > parameters. Hardcode the mandatory queue enqueue latency to 1. That is > > effectively what our internal memory systems do. > > Andreas Hansson wrote: > I find this suggestion a bit odd, but am not familiar enough with the > Ruby cache models to say what's best. Is the Ruby cache model only used for > L1s? If so, perhaps assuming a response always comes back the next cycle is > acceptable. If our intention is to have a model for Ln caches, then I find it > very strange to always assume one cycle. For the classic caches we have a > handful latency parameters to control the pipeline, memory, and lookup > latencies. I would expect something similar in the Ruby case. Am I missing > something?
I have looked at performance effects of L1 hit latencies for MOESI_hammer and derivative coherence protocols, and I've also seen the pipeline bubbles you referring to (NOTE: Your Ruby tester fix patch changes the sequencer clock domain to the Ruby/uncore frequency, which exacerbates this problem). I can't, however, speak to the effect of L1 latencies in other protocols. I also find this suggestion to be odd. We can't remove the parameters without also removing the ability to change the L1 hit latency, unless we modify all the top-level caches as I described in my response to Andreas. Also, changing the default hit latency for existing protocols would require revalidating their performance (stats), which is outside the scope of this patch. This patch only cleans up the L1 hit latency parameterization to give your desired outcome of not having to specify RubyCache latencies where they are unnecessary. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2841/#review6423 ----------------------------------------------------------- On May 21, 2015, 4:05 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2841/ > ----------------------------------------------------------- > > (Updated May 21, 2015, 4:05 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10838:d02a5584e395 > --------------------------- > 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/MOESI_CMP_token.py ecbab2522757 > configs/ruby/MOESI_hammer.py ecbab2522757 > configs/ruby/Network_test.py ecbab2522757 > src/mem/ruby/structures/Cache.py ecbab2522757 > src/mem/ruby/structures/CacheMemory.hh ecbab2522757 > src/mem/ruby/structures/CacheMemory.cc ecbab2522757 > src/mem/ruby/system/Sequencer.hh ecbab2522757 > src/mem/ruby/system/Sequencer.cc ecbab2522757 > src/mem/ruby/system/Sequencer.py ecbab2522757 > configs/ruby/MESI_Three_Level.py ecbab2522757 > configs/ruby/MESI_Two_Level.py ecbab2522757 > configs/ruby/MI_example.py ecbab2522757 > configs/ruby/MOESI_CMP_directory.py ecbab2522757 > > Diff: http://reviews.gem5.org/r/2841/diff/ > > > Testing > ------- > > Small tests with all different protocols to verify that performance does not > change. > > 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
