> On Oct. 11, 2012, 12:50 a.m., Andreas Hansson wrote: > > src/mem/ruby/buffers/MessageBuffer.cc, line 496 > > <http://reviews.gem5.org/r/1443/diff/3/?file=30233#file30233line496> > > > > Could there be order dependent behaviour here or somewhere else? The > > iteration over a map scares me quite a bit! > > > > In general, we should avoid it as the order is not defined. > > Nilay Vaish wrote: > In case of functional write, the order does not matter since all the > messages in > the memory system are updated. > > For functional reads, any packet that holds the data should be holding > the correct > data since we allow only exclusive writes. > > Andreas Hansson wrote: > Ok, perhaps I just don't understand the full implication of what is > happening. I would imagine that the messages would hold transient states, and > that the controllers would resolve them. Perhaps I'm just missing something > here.
Let there be two message A and B in the map. If a functional read request arrives which both of these packets can service, then I expect both the messages to hold the correct data. Hence, which ever one is looked at, it should not matter. If a functional write request needs service, then both the packets would be written to. Again, the order would not matter. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1443/#review3561 ----------------------------------------------------------- On Oct. 11, 2012, 3:47 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1443/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2012, 3:47 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9283:a755377671a5 > --------------------------- > ruby: improved support for functional accesses > This patch adds support to different entities in the ruby memory system > for more reliable functional read/write accesses. Only the simple network > has been augmented as of now. Later on Garnet will also support functional > accesses. > The patch adds functional access code to all the different types of messages > that protocols can send around. These messages are functionally accessed > by going through the buffers maintained by the network entities. > The patch also rectifies some of the bugs found in coherence protocols while > testing the patch. > > With this patch applied, functional writes always succeed. But functional > reads can still fail. > > > Diffs > ----- > > configs/example/ruby_mem_test.py a5ede748a1d9 > src/mem/protocol/MESI_CMP_directory-L1cache.sm a5ede748a1d9 > src/mem/protocol/MESI_CMP_directory-L2cache.sm a5ede748a1d9 > src/mem/protocol/MESI_CMP_directory-dir.sm a5ede748a1d9 > src/mem/protocol/MESI_CMP_directory-msg.sm a5ede748a1d9 > src/mem/protocol/MI_example-cache.sm a5ede748a1d9 > src/mem/protocol/MI_example-dir.sm a5ede748a1d9 > src/mem/protocol/MI_example-msg.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_directory-dir.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_directory-msg.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_token-L1cache.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_token-dir.sm a5ede748a1d9 > src/mem/protocol/MOESI_CMP_token-msg.sm a5ede748a1d9 > src/mem/protocol/MOESI_hammer-cache.sm a5ede748a1d9 > src/mem/protocol/MOESI_hammer-dir.sm a5ede748a1d9 > src/mem/protocol/MOESI_hammer-msg.sm a5ede748a1d9 > src/mem/protocol/Network_test-msg.sm a5ede748a1d9 > src/mem/protocol/RubySlicc_Exports.sm a5ede748a1d9 > src/mem/protocol/RubySlicc_MemControl.sm a5ede748a1d9 > src/mem/ruby/buffers/MessageBuffer.hh a5ede748a1d9 > src/mem/ruby/buffers/MessageBuffer.cc a5ede748a1d9 > src/mem/ruby/buffers/MessageBufferNode.hh a5ede748a1d9 > src/mem/ruby/network/Network.hh a5ede748a1d9 > src/mem/ruby/network/simple/PerfectSwitch.cc a5ede748a1d9 > src/mem/ruby/network/simple/SimpleNetwork.hh a5ede748a1d9 > src/mem/ruby/network/simple/SimpleNetwork.cc a5ede748a1d9 > src/mem/ruby/network/simple/Switch.hh a5ede748a1d9 > src/mem/ruby/network/simple/Switch.cc a5ede748a1d9 > src/mem/ruby/slicc_interface/AbstractController.hh a5ede748a1d9 > src/mem/ruby/slicc_interface/Message.hh a5ede748a1d9 > src/mem/ruby/slicc_interface/NetworkMessage.hh a5ede748a1d9 > src/mem/ruby/slicc_interface/RubyRequest.hh a5ede748a1d9 > src/mem/ruby/slicc_interface/RubyRequest.cc a5ede748a1d9 > src/mem/ruby/slicc_interface/RubySlicc_Util.hh a5ede748a1d9 > src/mem/ruby/system/MemoryControl.hh a5ede748a1d9 > src/mem/ruby/system/MemoryControl.cc a5ede748a1d9 > src/mem/ruby/system/RubyMemoryControl.hh a5ede748a1d9 > src/mem/ruby/system/RubyMemoryControl.cc a5ede748a1d9 > src/mem/ruby/system/System.cc a5ede748a1d9 > src/mem/slicc/ast/TypeDeclAST.py a5ede748a1d9 > src/mem/slicc/symbols/StateMachine.py a5ede748a1d9 > src/mem/slicc/symbols/SymbolTable.py a5ede748a1d9 > src/mem/slicc/symbols/Type.py a5ede748a1d9 > > Diff: http://reviews.gem5.org/r/1443/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
