> 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? > > Nilay Vaish wrote: > 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.
Yes, that is correct. With my recent change, directory entries also include access premissions which are automatically set by SLICC. You should be able to treat them th same way. - Brad ----------------------------------------------------------- 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
