> On 2011-10-18 07:38:59, Korey Sewell wrote: > > build_opts/ALPHA_SE_MESI_CMP_directory, line 3 > > <http://reviews.m5sim.org/r/894/diff/1/?file=15295#file15295line3> > > > > Do you really want to remove support for all the other CPU models?
I did that just for testing purpose. I will ensure that this not part of the final commit. > On 2011-10-18 07:38:59, Korey Sewell wrote: > > configs/ruby/MESI_CMP_directory.py, line 75 > > <http://reviews.m5sim.org/r/894/diff/1/?file=15297#file15297line75> > > > > 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) In case of timingSimpleCPU, the CPU stalls until the access is made. I don't think that the CPU needs invalidations / replacements from Ruby. Hence, I made that option available. We can always set it so that both detailed and inorder CPU's would receive invalidations but timingSimpleCPU would not. > On 2011-10-18 07:38:59, Korey Sewell wrote: > > src/mem/ruby/system/RubyPort.cc, line 685 > > <http://reviews.m5sim.org/r/894/diff/1/?file=15301#file15301line685> > > > > 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? With a very high probability, I might be doing things incorrectly. I copied this code from the src/mem/cache/cache_impl.hh. Since Ruby only has directory-based protocols currently, so this is not exactly instantaneous. We can schedule an event in future, if that's what we want. But from reading the code in cache_impl.hh, it seemed to me that invalidations are happening instantaneously. As far as asserting MEM_INHIBIT is concerned, it might be that it is completely unnecessary. I don't know why it is asserted in case of the classic memory system. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/894/#review1611 ----------------------------------------------------------- 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
