> On 2011-11-18 15:30:25, Nilay Vaish wrote: > >
The patch has been changed so that evictions are forwarded by all the coherence protocols. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/894/#review1664 ----------------------------------------------------------- On 2011-11-18 15:33:07, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/894/ > ----------------------------------------------------------- > > (Updated 2011-11-18 15:33:07) > > > Review request for Default. > > > Summary > ------- > > O3, Ruby: Forward invalidations from Ruby to O3 CPU > This patch implements the functionality for forwarding invalidations and > replacements from the L1 cache of the Ruby memory system to the O3 CPU. The > implementation adds a list of ports to RubyPort. Whenever a replacement or an > invalidation is performed, the L1 cache forwards this to all the ports, which > I believe is the LSQ in case of the O3 CPU. Those who understand the O3 LSQ > should take a close look at the implementation and figure out (at least > qualitatively) if some thing is missing or erroneous. > > A couple of issues that need discussion -- > > * How to avoid deadlock in the O3 CPU? The CPU may not be able to proceed if a > particularly cache block is repeatedly invalidated before the CPU can retire > the actual load/store instruction. How do we ensure that at least one > instruction is retired before an invalidation/replacement is processed? > > * How to test this implementation? Is it possible to implement some of the > tests that we regularly come across in papers on consistency models? Or those > present in manuals from AMD and Intel? I have tested that Ruby will forward > the invalidations, but not the part where the LSQ needs to act on it. > > > Diffs > ----- > > configs/example/se.py 330f8109b199 > configs/ruby/MESI_CMP_directory.py 330f8109b199 > configs/ruby/MI_example.py 330f8109b199 > configs/ruby/MOESI_CMP_directory.py 330f8109b199 > configs/ruby/MOESI_CMP_token.py 330f8109b199 > configs/ruby/MOESI_hammer.py 330f8109b199 > src/mem/protocol/MESI_CMP_directory-L1cache.sm 330f8109b199 > src/mem/protocol/MI_example-cache.sm 330f8109b199 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm 330f8109b199 > src/mem/protocol/MOESI_CMP_token-L1cache.sm 330f8109b199 > src/mem/protocol/MOESI_hammer-cache.sm 330f8109b199 > src/mem/protocol/RubySlicc_Types.sm 330f8109b199 > src/mem/ruby/system/RubyPort.hh 330f8109b199 > src/mem/ruby/system/RubyPort.cc 330f8109b199 > src/mem/ruby/system/Sequencer.hh 330f8109b199 > src/mem/ruby/system/Sequencer.cc 330f8109b199 > > Diff: http://reviews.m5sim.org/r/894/diff > > > Testing > ------- > > > Thanks, > > Nilay > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
