----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2841/#review6423 -----------------------------------------------------------
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. - Brad Beckmann 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
