----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/894/#review1664 -----------------------------------------------------------
- Nilay On 2011-11-18 15:28:45, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/894/ > ----------------------------------------------------------- > > (Updated 2011-11-18 15:28:45) > > > 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. > > This patch only modifies the MESI CMP directory protocol. I will modify other > protocols once we sort the major issues surrounding this patch. > > My understanding is that this should ensure an SC execution, as long as Ruby > can support SC. But I think Ruby does not support any memory model currently. > A couple of issues that need discussion -- > > * Can this get in to a deadlock? A 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
