----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/894/#review1611 -----------------------------------------------------------
build_opts/ALPHA_SE_MESI_CMP_directory <http://reviews.m5sim.org/r/894/#comment2092> Do you really want to remove support for all the other CPU models? configs/ruby/MESI_CMP_directory.py <http://reviews.m5sim.org/r/894/#comment2090> Hi Nilay, thanks for starting the work on this. I've been waffling on giving it a go for awhile now, so hopefully your push will get this rolling. Do you think that sending invalidations should be optional? For testing, this would be useful, but in general I would think you should always forward the invalidations to the CPU model and then the CPU model would choose to use that info or not (for instance, a inorder model may even buffer multiple speculative loads behind a blocking memory op) src/mem/ruby/system/RubyPort.cc <http://reviews.m5sim.org/r/894/#comment2091> Sanity Checks: (1) Is express snoop right here? That will make the snoop instantaneous right? Is that necessary if this just going directly to an L1? (2) Also, where does the meminhibit flag get deasserted? - Korey 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
