----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/894/#review1620 -----------------------------------------------------------
Thanks for the heads up on this patch. I'm glad you found the time to dive into it. I'm confused that the comment mentions a "list of ports", but I don't see a list of ports in the code and I'm not sure how would even be used? The two questions you pose are good ones. Hopefully someone who understands the O3 LSQ can answer the first, and I would suggest creating a new directed test that can manipulate the enqueue latency on the mandatory queue to create the necessary test situations. Also, I have a couple high-level comments right now: - Ruby doesn't implement any particular memory model. It just implements the cache coherence protocol, and more specifically invalidation based protocols. The protocol, in combination with the core model, results in the memory model. - I don't think it is sufficient to just forward those probes that hit valid copies to the O3 model. What about replacements of blocks that have serviced a speculative load? Instead, my thought would be to forward all probes to the O3 LSQ and think of cpu-controlled policies to filter out unecessary probes. - Brad On 2011-10-17 23:50:47, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/894/ > ----------------------------------------------------------- > > (Updated 2011-10-17 23:50:47) > > > Review request for Default. > > > Summary > ------- > > 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 > ----- > > build_opts/ALPHA_SE_MESI_CMP_directory 92ba80d63abc > configs/example/se.py 92ba80d63abc > configs/ruby/MESI_CMP_directory.py 92ba80d63abc > src/mem/protocol/MESI_CMP_directory-L1cache.sm 92ba80d63abc > src/mem/protocol/RubySlicc_Types.sm 92ba80d63abc > src/mem/ruby/system/RubyPort.hh 92ba80d63abc > src/mem/ruby/system/RubyPort.cc 92ba80d63abc > src/mem/ruby/system/Sequencer.hh 92ba80d63abc > src/mem/ruby/system/Sequencer.cc 92ba80d63abc > > Diff: http://reviews.m5sim.org/r/894/diff > > > Testing > ------- > > > Thanks, > > Nilay > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
