> On 2011-03-31 11:11:03, Brad Beckmann wrote: > > src/mem/ruby/system/RubyPort.cc, line 321 > > <http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321> > > > > This loop is probably the most complicated and important part of this > > patch. It might be easiest if we move this functionality into two > > different functions, one for reads and one for writes. > > > > The read scan just needs to ensure that at least one memory says that > > it has the address in Read_Only or ReadWrite state. We may also want to > > doublecheck that multiple memories say they have the address in ReadWrite > > state. > > > > The write scan is more complicated. If one memory says that it has the > > address in ReadWrite state, then I don't think it matters what state the > > other memories are in (except of course if another memory says it also has > > the address in ReadWrite), the write should succeed. Also if the write > > scans says that all copies are in Read_Only or Invalid/NotPresent state and > > no copies are Busy, the write should succeed. However, writes should fail > > if either no Read_Only or ReadWrite copies are found, or if a Busy copy is > > found and no ReadWrite copy is found. The latter situation will likely > > indicate the functional write is racing with a timing write. There is no > > easy, protocol-agnostic way to resolve such a race in the current > > infrastructure. > > > > Make sense? > > Nilay Vaish wrote: > I think we should have the following cases for functional writes -- > 1. Only read only copies --> write succeeds > 2. One read write copy --> write succeeds > 3. At least one busy --> write fails. > 4. None of the above, then simply update the memory. Memory should > also get updated in 1. as well. > > Brad, from your comment it seems that you expect that there can be > multiple read-write copies simultaneously. Is this possible, or would > this be a bug in the protocol? > > Brad Beckmann wrote: > You are absolutely right, that would be an error in the protocol. It > just seems that since we are scanning the state of the address in the system, > we might as well double check that at most one ReadWrite copy exists. > > I completely agree with your first two cases. However, I think the third > case is slightly too restrictive. Just because one memory has the address as > Busy, doesn't necessarily mean that we cannot update the block. If another > memory has the block in read-write state, we can be certain that that > particular copy is not only still valid, but has also yet to relinquish > exclusive ownership. Therefore a function write to that block can succeed. > Meanwhile, if we find a Busy block and just Read_Only block(s), than other > valid copies may exist somewhere in the system and thus the functional write > likely won't succeed. > > I'm confused by your fourth case. Isn't Ruby memory (a.k.a. > DirectoryMemory) just another AbstractMemory object and thus just another > memory in the list of memories? My hope was that we would treat CacheMemory > and DirectoryMemory the same when doing functional accesses. Am I missing > something?
Brad, put it down to my lack of understanding of how the memory has been organized. Currently, it seems to me that directory memory will either have a sparse memory vector or a memory vector. These will contain the directory entries. It is these directory entries which hold the data blocks, which would be handled in a fashion similar to cache entries. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1054 ----------------------------------------------------------- On 2011-03-31 20:44:17, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > ----------------------------------------------------------- > > (Updated 2011-03-31 20:44:17) > > > Review request for Default. > > > Summary > ------- > > Ruby: Add support for functional accesses > This patch is meant for aiding discussions on implementation of functional > access support in Ruby. > > > Diffs > ----- > > configs/ruby/MESI_CMP_directory.py c7302d55d644 > configs/ruby/Ruby.py c7302d55d644 > src/mem/ruby/network/Network.cc c7302d55d644 > src/mem/ruby/network/Network.py c7302d55d644 > src/mem/ruby/profiler/Profiler.cc c7302d55d644 > src/mem/ruby/profiler/Profiler.py c7302d55d644 > src/mem/ruby/recorder/Tracer.cc c7302d55d644 > src/mem/ruby/recorder/Tracer.py c7302d55d644 > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/Cache.py c7302d55d644 > src/mem/ruby/system/CacheMemory.hh c7302d55d644 > src/mem/ruby/system/CacheMemory.cc c7302d55d644 > src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 > src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 > src/mem/ruby/system/DirectoryMemory.py c7302d55d644 > src/mem/ruby/system/RubyPort.hh c7302d55d644 > src/mem/ruby/system/RubyPort.cc c7302d55d644 > src/mem/ruby/system/RubySystem.py c7302d55d644 > src/mem/ruby/system/SConscript c7302d55d644 > src/mem/ruby/system/Sequencer.cc c7302d55d644 > src/mem/ruby/system/Sequencer.py c7302d55d644 > src/mem/ruby/system/System.hh c7302d55d644 > src/mem/ruby/system/System.cc c7302d55d644 > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > ------- > > > Thanks, > > Nilay > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
