> 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? > > Joel Hestness wrote: > 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.
Let's revive this discussion. I like this patch overall. I just want to make sure that folks use a L1 cache latency of 1 by default. The O3+Ruby model is broken without that change. Joel, can you comment on making the change I suggested below? Thanks. - Brad ----------------------------------------------------------- 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
