Discussion:
[gem5-dev] Review Request: ruby: augment network to support functional accesses
(too old to reply)
Nilay Vaish
2012-09-25 01:15:47 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------

Review request for Default.


Description
-------

Changeset 9257:5bd46130593a
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.


Diffs
-----

src/mem/protocol/MESI_CMP_directory-dir.sm 73c3eb0dd733
src/mem/protocol/MESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MI_example-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-L1cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_hammer-msg.sm 73c3eb0dd733
src/mem/protocol/Network_test-msg.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Exports.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_MemControl.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Util.sm 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.hh 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.cc 73c3eb0dd733
src/mem/ruby/buffers/MessageBufferNode.hh 73c3eb0dd733
src/mem/ruby/network/Network.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/PerfectSwitch.cc 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.hh 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/Switch.hh 73c3eb0dd733
src/mem/ruby/network/simple/Switch.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/AbstractController.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/Message.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/NetworkMessage.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 73c3eb0dd733
src/mem/ruby/system/System.cc 73c3eb0dd733
src/mem/slicc/ast/TypeDeclAST.py 73c3eb0dd733
src/mem/slicc/symbols/StateMachine.py 73c3eb0dd733
src/mem/slicc/symbols/SymbolTable.py 73c3eb0dd733
src/mem/slicc/symbols/Type.py 73c3eb0dd733

Diff: http://reviews.gem5.org/r/1443/diff/


Testing
-------


Thanks,

Nilay Vaish
Andreas Hansson
2012-09-26 22:18:54 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3520
-----------------------------------------------------------


Seems fine to me. Anything on the testing?

- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Sept. 24, 2012, 6:15 p.m.)
Review request for Default.
Description
-------
Changeset 9257:5bd46130593a
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.
Diffs
-----
src/mem/protocol/MESI_CMP_directory-dir.sm 73c3eb0dd733
src/mem/protocol/MESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MI_example-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-L1cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_hammer-msg.sm 73c3eb0dd733
src/mem/protocol/Network_test-msg.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Exports.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_MemControl.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Util.sm 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.hh 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.cc 73c3eb0dd733
src/mem/ruby/buffers/MessageBufferNode.hh 73c3eb0dd733
src/mem/ruby/network/Network.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/PerfectSwitch.cc 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.hh 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/Switch.hh 73c3eb0dd733
src/mem/ruby/network/simple/Switch.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/AbstractController.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/Message.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/NetworkMessage.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 73c3eb0dd733
src/mem/ruby/system/System.cc 73c3eb0dd733
src/mem/slicc/ast/TypeDeclAST.py 73c3eb0dd733
src/mem/slicc/symbols/StateMachine.py 73c3eb0dd733
src/mem/slicc/symbols/SymbolTable.py 73c3eb0dd733
src/mem/slicc/symbols/Type.py 73c3eb0dd733
Diff: http://reviews.gem5.org/r/1443/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2012-09-28 03:06:51 UTC
Permalink
Post by Nilay Vaish
Post by Andreas Hansson
Seems fine to me. Anything on the testing?
The failing regression test now completes, though I am unsure why it passes.
My main purpose with this patch in particular was to get a feedback on the
approach being taken since Brad and I are not in agreement.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3520
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Sept. 24, 2012, 6:15 p.m.)
Review request for Default.
Description
-------
Changeset 9257:5bd46130593a
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.
Diffs
-----
src/mem/protocol/MESI_CMP_directory-dir.sm 73c3eb0dd733
src/mem/protocol/MESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MI_example-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-L1cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_hammer-msg.sm 73c3eb0dd733
src/mem/protocol/Network_test-msg.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Exports.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_MemControl.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Util.sm 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.hh 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.cc 73c3eb0dd733
src/mem/ruby/buffers/MessageBufferNode.hh 73c3eb0dd733
src/mem/ruby/network/Network.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/PerfectSwitch.cc 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.hh 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/Switch.hh 73c3eb0dd733
src/mem/ruby/network/simple/Switch.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/AbstractController.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/Message.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/NetworkMessage.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 73c3eb0dd733
src/mem/ruby/system/System.cc 73c3eb0dd733
src/mem/slicc/ast/TypeDeclAST.py 73c3eb0dd733
src/mem/slicc/symbols/StateMachine.py 73c3eb0dd733
src/mem/slicc/symbols/SymbolTable.py 73c3eb0dd733
src/mem/slicc/symbols/Type.py 73c3eb0dd733
Diff: http://reviews.gem5.org/r/1443/diff/
Testing
-------
Thanks,
Nilay Vaish
Brad Beckmann
2012-09-27 04:21:25 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3529
-----------------------------------------------------------


I have a couple questions:
- Why do you modify the msg.sm files? It seems unecessary.
- How do you handle functional writes to message buffers no part of the network?

As you already know, I'm in favor of just creating a list of message buffers by modifying the MessageBuffer constructor. After seeing the number of files you had to change with this existing patch, I'm further convinced that is the better approach. This current patch seems quite hackish, and adding this support to Garnet is only going to be uglier. What can I do to convince you that the MessageBuffer approach is better? Or in other words, can you explain exactly what you don't like about the MessageBuffer approach?


src/mem/protocol/MESI_CMP_directory-dir.sm
<http://reviews.gem5.org/r/1443/#comment3542>

Whitespace change?



src/mem/ruby/slicc_interface/NetworkMessage.hh
<http://reviews.gem5.org/r/1443/#comment3541>

Why don't you define and implement the functionalWrite function here in NetworkMessage. It seems unecessary to have to modify any .sm files.


- Brad Beckmann
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Sept. 24, 2012, 6:15 p.m.)
Review request for Default.
Description
-------
Changeset 9257:5bd46130593a
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.
Diffs
-----
src/mem/protocol/MESI_CMP_directory-dir.sm 73c3eb0dd733
src/mem/protocol/MESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MI_example-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_directory-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-L1cache.sm 73c3eb0dd733
src/mem/protocol/MOESI_CMP_token-msg.sm 73c3eb0dd733
src/mem/protocol/MOESI_hammer-msg.sm 73c3eb0dd733
src/mem/protocol/Network_test-msg.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Exports.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_MemControl.sm 73c3eb0dd733
src/mem/protocol/RubySlicc_Util.sm 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.hh 73c3eb0dd733
src/mem/ruby/buffers/MessageBuffer.cc 73c3eb0dd733
src/mem/ruby/buffers/MessageBufferNode.hh 73c3eb0dd733
src/mem/ruby/network/Network.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 73c3eb0dd733
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 73c3eb0dd733
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/PerfectSwitch.cc 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.hh 73c3eb0dd733
src/mem/ruby/network/simple/SimpleNetwork.cc 73c3eb0dd733
src/mem/ruby/network/simple/Switch.hh 73c3eb0dd733
src/mem/ruby/network/simple/Switch.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/AbstractController.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/Message.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/NetworkMessage.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.hh 73c3eb0dd733
src/mem/ruby/slicc_interface/RubyRequest.cc 73c3eb0dd733
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 73c3eb0dd733
src/mem/ruby/system/System.cc 73c3eb0dd733
src/mem/slicc/ast/TypeDeclAST.py 73c3eb0dd733
src/mem/slicc/symbols/StateMachine.py 73c3eb0dd733
src/mem/slicc/symbols/SymbolTable.py 73c3eb0dd733
src/mem/slicc/symbols/Type.py 73c3eb0dd733
Diff: http://reviews.gem5.org/r/1443/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2012-09-28 03:03:53 UTC
Permalink
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/#review3529
-----------------------------------------------------------
- Why do you modify the msg.sm files? It seems unecessary.
Each class that inherits from the Message/NetworkMessage class can
potentially hold the <address, datablock> that needs to be accessed
functionally. The question here is what assumptions do we want to make on
these classes. I am trying to strive for a solution where we do not have
any restrictions. For example, can we assume that each of these classes
will have exactly one data block?
Post by Nilay Vaish
- How do you handle functional writes to message buffers no part of the network?
I am assuming that only other buffers are the ones in the
cache/directory/dma/ controllers. A separate call is made to functionally
access these buffers.
Post by Nilay Vaish
As you already know, I'm in favor of just creating a list of message
buffers by modifying the MessageBuffer constructor. After seeing the
number of files you had to change with this existing patch, I'm further
convinced that is the better approach. This current patch seems quite
hackish, and adding this support to Garnet is only going to be uglier.
What can I do to convince you that the MessageBuffer approach is better?
Or in other words, can you explain exactly what you don't like about the
MessageBuffer approach?
I think that going via network is better. Firstly, the list that would
need to be created for accessing the buffers in the memory system, already
exists as part of the network hierarchy we have. Secondly, it seems to
that it would easier to debug if traverse the network in a structured
manner rather than traversing a flat list.

--
Nilay
Beckmann, Brad
2012-09-28 16:43:07 UTC
Permalink
Post by Nilay Vaish
Post by Brad Beckmann
- Why do you modify the msg.sm files? It seems unecessary.
Each class that inherits from the Message/NetworkMessage class can
potentially hold the <address, datablock> that needs to be accessed
functionally. The question here is what assumptions do we want to make on
these classes. I am trying to strive for a solution where we do not have any
restrictions. For example, can we assume that each of these classes will have
exactly one data block?
Yes, this is a tradeoff of flexibility vs. elegance. Certainly Ruby/Slicc has precedence to favor the former. I'm not excited to have to modify all msg.sm files to support functional accesses, but maybe I/we were fooling ourselves earlier that support functional accesses could be relatively invisible to the slicc programmer. This change puts that hope to rest. Oh well. I don't want to sacrifice flexibility.
Post by Nilay Vaish
Post by Brad Beckmann
- How do you handle functional writes to message buffers no part of the
network?
I am assuming that only other buffers are the ones in the
cache/directory/dma/ controllers. A separate call is made to functionally
access these buffers.
Post by Brad Beckmann
As you already know, I'm in favor of just creating a list of message
buffers by modifying the MessageBuffer constructor. After seeing the
number of files you had to change with this existing patch, I'm further
convinced that is the better approach. This current patch seems quite
hackish, and adding this support to Garnet is only going to be uglier.
What can I do to convince you that the MessageBuffer approach is better?
Or in other words, can you explain exactly what you don't like about the
MessageBuffer approach?
I think that going via network is better. Firstly, the list that would
need to be created for accessing the buffers in the memory system, already
exists as part of the network hierarchy we have. Secondly, it seems to
that it would easier to debug if traverse the network in a structured
manner rather than traversing a flat list.
How is traversing the network plus calling all controllers to update their message buffers easier than just creating a flat list? Precedence in the simulator is that creating a flat list is better. For example, to drain the system, the flat list of SimObjects is traversed, not the configuration graph.

Brad
Nilay Vaish
2012-09-30 22:03:10 UTC
Permalink
Post by Beckmann, Brad
Post by Nilay Vaish
I am assuming that only other buffers are the ones in the
cache/directory/dma/ controllers. A separate call is made to functionally
access these buffers.
Post by Brad Beckmann
As you already know, I'm in favor of just creating a list of message
buffers by modifying the MessageBuffer constructor. After seeing the
number of files you had to change with this existing patch, I'm further
convinced that is the better approach. This current patch seems quite
hackish, and adding this support to Garnet is only going to be uglier.
What can I do to convince you that the MessageBuffer approach is better?
Or in other words, can you explain exactly what you don't like about the
MessageBuffer approach?
I think that going via network is better. Firstly, the list that would
need to be created for accessing the buffers in the memory system, already
exists as part of the network hierarchy we have. Secondly, it seems to
that it would easier to debug if traverse the network in a structured
manner rather than traversing a flat list.
How is traversing the network plus calling all controllers to update
their message buffers easier than just creating a flat list?
Precedence in the simulator is that creating a flat list is better.
For example, to drain the system, the flat list of SimObjects is
traversed, not the configuration graph.
I would be surprised if that is the case. I certainly would not create a
new structure when one already exists, unless the new structure allows for
some operation that could not have been possible otherwise.

--
Nilay
Beckmann, Brad
2012-10-01 16:48:56 UTC
Permalink
-----Original Message-----
Sent: Sunday, September 30, 2012 3:03 PM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: ruby: augment network to support functional
accesses
Post by Beckmann, Brad
Post by Nilay Vaish
I am assuming that only other buffers are the ones in the
cache/directory/dma/ controllers. A separate call is made to
functionally access these buffers.
Post by Brad Beckmann
As you already know, I'm in favor of just creating a list of message
buffers by modifying the MessageBuffer constructor. After seeing
the number of files you had to change with this existing patch, I'm
further convinced that is the better approach. This current patch
seems quite hackish, and adding this support to Garnet is only going to
be uglier.
Post by Beckmann, Brad
Post by Nilay Vaish
Post by Brad Beckmann
What can I do to convince you that the MessageBuffer approach is
better?
Post by Beckmann, Brad
Post by Nilay Vaish
Post by Brad Beckmann
Or in other words, can you explain exactly what you don't like about
the MessageBuffer approach?
I think that going via network is better. Firstly, the list that
would need to be created for accessing the buffers in the memory
system, already exists as part of the network hierarchy we have.
Secondly, it seems to that it would easier to debug if traverse the
network in a structured manner rather than traversing a flat list.
How is traversing the network plus calling all controllers to update
their message buffers easier than just creating a flat list?
Precedence in the simulator is that creating a flat list is better.
For example, to drain the system, the flat list of SimObjects is
traversed, not the configuration graph.
I would be surprised if that is the case. I certainly would not create a
new structure when one already exists, unless the new structure allows for
some operation that could not have been possible otherwise.
--
Nilay
But the structure doesn't already exist...that's my point. We only have the network structure, which is a graph data structure of a whole bunch of things, including *some* MessageBuffers. Other MessgeBuffers are embedded within the controllers and are inaccessible by the network. Overall, you have to deal with a bunch of complicated data structures with this strategy. Meanwhile the flat list of MessageBuffers is simple.

Brad
Nilay Vaish
2012-10-01 19:50:35 UTC
Permalink
Post by Beckmann, Brad
-----Original Message-----
Sent: Sunday, September 30, 2012 3:03 PM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: ruby: augment network to support functional
accesses
Post by Beckmann, Brad
Post by Nilay Vaish
I am assuming that only other buffers are the ones in the
cache/directory/dma/ controllers. A separate call is made to
functionally access these buffers.
Post by Brad Beckmann
As you already know, I'm in favor of just creating a list of message
buffers by modifying the MessageBuffer constructor. After seeing
the number of files you had to change with this existing patch, I'm
further convinced that is the better approach. This current patch
seems quite hackish, and adding this support to Garnet is only going to
be uglier.
Post by Beckmann, Brad
Post by Nilay Vaish
Post by Brad Beckmann
What can I do to convince you that the MessageBuffer approach is
better?
Post by Beckmann, Brad
Post by Nilay Vaish
Post by Brad Beckmann
Or in other words, can you explain exactly what you don't like about
the MessageBuffer approach?
I think that going via network is better. Firstly, the list that
would need to be created for accessing the buffers in the memory
system, already exists as part of the network hierarchy we have.
Secondly, it seems to that it would easier to debug if traverse the
network in a structured manner rather than traversing a flat list.
How is traversing the network plus calling all controllers to update
their message buffers easier than just creating a flat list?
Precedence in the simulator is that creating a flat list is better.
For example, to drain the system, the flat list of SimObjects is
traversed, not the configuration graph.
I would be surprised if that is the case. I certainly would not create a
new structure when one already exists, unless the new structure allows for
some operation that could not have been possible otherwise.
--
Nilay
But the structure doesn't already exist...that's my point. We only have
the network structure, which is a graph data structure of a whole bunch
of things, including *some* MessageBuffers. Other MessgeBuffers are
embedded within the controllers and are inaccessible by the network.
Overall, you have to deal with a bunch of complicated data structures
with this strategy. Meanwhile the flat list of MessageBuffers is
simple.
Brad, I think we are getting into a needless debate. If you want, you can
change it later to a flat list. There are greater issues that need to be
tackled before this patch is making it to the repo.

--
Nilay
Nilay Vaish
2012-10-04 04:12:29 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------

(Updated Oct. 3, 2012, 9:12 p.m.)


Review request for Default.


Description (updated)
-------

Changeset 9283:0da5f7f0cf48
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.


Diffs (updated)
-----

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
Nilay Vaish
2012-10-04 05:01:57 UTC
Permalink
Some comments on the patch --

* The way the code has been written, functional writes will always
succeed, but functional reads can still fail. This can be illustrated with
an example. Consider the situation when the directory has the actual
data, but it believes that the ownership of the data is with some other
controller. This other controller has relinquished the ownership with out
modifying the data. The info about relinquishment is in the network
currently. The read would fail since we need to know both pieces of info
to figure out that the directory has the data. We would need greater
cooperation from protocols for reads to succeed all the time.

* I have done some testing with the memtest (1 to 8 cores, 160000 loads).
But no testing has been done when dma requests/replies are part of the
system.

* No support for garnet as of now.

* Coherence protocols MI, MOESI CMP token have been changed slightly.
These changes have been vetted only with the memtest.

--
Nilay
Beckmann, Brad
2012-10-05 17:52:17 UTC
Permalink
Hi Nilay,

To solve the first problem, can you use the Maybe_Stale AccessPermission identify the last possible valid copy of the data block? It seems like if a functional read can't find valid data anywhere else, then you are guaranteed that the Maybe_Stale block at the directory is valid.

With this change, we should be able to get rid of the physmem backing store in Ruby, correct? Have you tried that sort of test with this patch? Especially an application under SE mode that uses a lot of system calls?

45 files modified...have I told you how much I dislike this patch. :)

Brad
-----Original Message-----
Sent: Wednesday, October 03, 2012 10:02 PM
To: Andreas Hansson; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: augment network to support functional
accesses
Some comments on the patch --
* The way the code has been written, functional writes will always succeed,
but functional reads can still fail. This can be illustrated with an example.
Consider the situation when the directory has the actual data, but it believes
that the ownership of the data is with some other controller. This other
controller has relinquished the ownership with out modifying the data. The
info about relinquishment is in the network currently. The read would fail
since we need to know both pieces of info to figure out that the directory
has the data. We would need greater cooperation from protocols for reads
to succeed all the time.
* I have done some testing with the memtest (1 to 8 cores, 160000 loads).
But no testing has been done when dma requests/replies are part of the
system.
* No support for garnet as of now.
* Coherence protocols MI, MOESI CMP token have been changed slightly.
These changes have been vetted only with the memtest.
--
Nilay
Nilay Vaish
2012-10-06 12:36:07 UTC
Permalink
Post by Beckmann, Brad
Hi Nilay,
To solve the first problem, can you use the Maybe_Stale AccessPermission
identify the last possible valid copy of the data block? It seems like
if a functional read can't find valid data anywhere else, then you are
guaranteed that the Maybe_Stale block at the directory is valid.
I think this solution will not work. It is possible that two controllers
at two different levels have a block with access permission Maybe_Stale.
In that case, unless we have the hierarchical information, we would not be
able to figure out which block to read. It seems it would not hard to add
this hierarchy information to the existing protocols, and then we can add
a hierarchical list of controllers to the ruby system.
Post by Beckmann, Brad
With this change, we should be able to get rid of the physmem backing
store in Ruby, correct? Have you tried that sort of test with this
patch? Especially an application under SE mode that uses a lot of
system calls?
I never thought about removing the backing physical memory. But now that
you mention it, if the cache and directory controllers are the only ones
who should be writing to the memory (which I think is true in the SE
mode), then it should be possible to remove the backing physical memory.
This might lead to bugs being uncovered in the coherence protocols.
Post by Beckmann, Brad
45 files modified...have I told you how much I dislike this patch. :)
I agree that a lot of files are being changed. With a high probability,
anyone who has modified Ruby would need to redo his/her patches. But then
I don't see if any changes can be elided. Even if I were to go with your
suggestion of building a flat list of buffers, most of the changes would
still remain as is.
Post by Beckmann, Brad
Brad
-----Original Message-----
Sent: Wednesday, October 03, 2012 10:02 PM
To: Andreas Hansson; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: augment network to support functional
accesses
Some comments on the patch --
* The way the code has been written, functional writes will always succeed,
but functional reads can still fail. This can be illustrated with an example.
Consider the situation when the directory has the actual data, but it believes
that the ownership of the data is with some other controller. This other
controller has relinquished the ownership with out modifying the data. The
info about relinquishment is in the network currently. The read would fail
since we need to know both pieces of info to figure out that the directory
has the data. We would need greater cooperation from protocols for reads
to succeed all the time.
* I have done some testing with the memtest (1 to 8 cores, 160000 loads).
But no testing has been done when dma requests/replies are part of the
system.
* No support for garnet as of now.
* Coherence protocols MI, MOESI CMP token have been changed slightly.
These changes have been vetted only with the memtest.
--
Nilay
--
Nilay
Andreas Hansson
2012-10-07 15:11:59 UTC
Permalink
Hi guys,

I am very much inclined to support Brad's approach, which doesn't care
about the "physical" topology of the interconnect.

Also, I don't want to de-rail the discussion, but an idea that I came to
think of based on all my previous NoC work, do you really need to enquire
the router network at all? Isn't the state always determined what the
controllers and end-points see? What happens if the network only sees
"packets" and has no clue about the actual higher-level messages (which is
the case in plenty real NoC implementations)?

Andreas
Post by Nilay Vaish
Post by Beckmann, Brad
Hi Nilay,
To solve the first problem, can you use the Maybe_Stale
AccessPermission
identify the last possible valid copy of the data block? It seems like
if a functional read can't find valid data anywhere else, then you are
guaranteed that the Maybe_Stale block at the directory is valid.
I think this solution will not work. It is possible that two controllers
at two different levels have a block with access permission Maybe_Stale.
In that case, unless we have the hierarchical information, we would not be
able to figure out which block to read. It seems it would not hard to add
this hierarchy information to the existing protocols, and then we can add
a hierarchical list of controllers to the ruby system.
Post by Beckmann, Brad
With this change, we should be able to get rid of the physmem backing
store in Ruby, correct? Have you tried that sort of test with this
patch? Especially an application under SE mode that uses a lot of
system calls?
I never thought about removing the backing physical memory. But now that
you mention it, if the cache and directory controllers are the only ones
who should be writing to the memory (which I think is true in the SE
mode), then it should be possible to remove the backing physical memory.
This might lead to bugs being uncovered in the coherence protocols.
Post by Beckmann, Brad
45 files modified...have I told you how much I dislike this patch. :)
I agree that a lot of files are being changed. With a high probability,
anyone who has modified Ruby would need to redo his/her patches. But then
I don't see if any changes can be elided. Even if I were to go with your
suggestion of building a flat list of buffers, most of the changes would
still remain as is.
Post by Beckmann, Brad
Brad
-----Original Message-----
Sent: Wednesday, October 03, 2012 10:02 PM
To: Andreas Hansson; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: augment network to support functional
accesses
Some comments on the patch --
* The way the code has been written, functional writes will always succeed,
but functional reads can still fail. This can be illustrated with an example.
Consider the situation when the directory has the actual data, but it believes
that the ownership of the data is with some other controller. This other
controller has relinquished the ownership with out modifying the data. The
info about relinquishment is in the network currently. The read would fail
since we need to know both pieces of info to figure out that the directory
has the data. We would need greater cooperation from protocols for reads
to succeed all the time.
* I have done some testing with the memtest (1 to 8 cores, 160000 loads).
But no testing has been done when dma requests/replies are part of the
system.
* No support for garnet as of now.
* Coherence protocols MI, MOESI CMP token have been changed slightly.
These changes have been vetted only with the memtest.
--
Nilay
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay Vaish
2012-10-07 17:24:20 UTC
Permalink
Post by Andreas Hansson
Hi guys,
I am very much inclined to support Brad's approach, which doesn't care
about the "physical" topology of the interconnect.
Also, I don't want to de-rail the discussion, but an idea that I came to
think of based on all my previous NoC work, do you really need to enquire
the router network at all? Isn't the state always determined what the
controllers and end-points see? What happens if the network only sees
"packets" and has no clue about the actual higher-level messages (which is
the case in plenty real NoC implementations)?
There are several things that I believe you are missing out on.

* The claim that the network does not need to enquired at all is
incorrect. It is possible that the data is in some packet in the network,
and hence the network buffers need to be searched for that packet.
Secondly, it seems to me that the network hierarchy it self can store some
information that is required for making a functional access. I have not
proven this yet.

* A real NoC implementation does not support functional accesses. Anyway,
I am not assuming any particular structure on the packets themselves,
except that they provide a function for making a functional read/write
access. Changes have been made to the higher level messages to support
those functions.

* I have stated before that I am not opposed to having flat list of
buffers. But it is not the approach that I prefer.

--
Nilay
Beckmann, Brad
2012-10-08 17:35:43 UTC
Permalink
Hi Nilay,

A few more comments/responses:

- Good point about the possible hierarchy of Maybe_Stale blocks. My suggestion is to check that you only have one Maybe_Stale block in the situation where you have to satisfy a functional read with a Maybe_Stale block. Only in the situation where you have multiple Maybe_Stale blocks do you fail the functional read.
- If you were to use the flat list approach, I believe you would avoid having to touch SLICC or the network. I agree that you still have to touch around half of the files that you do now, but I do think you'd see a significant savings in files modified and complexity. That being said, this is your patch, and you're going to own it. The final call is yours. Selfishly I really don't want to see the SLICC changes because I have a huge SLICC patch in the works that I'm going to have to rebase based on these changes.
- In general, you need to add comments to this patch. I identified on particular set of functions on ReviewBoard, but there are many other places that comments would be appropriate.

Brad
-----Original Message-----
Sent: Sunday, October 07, 2012 10:24 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request: ruby: augment network to support
functional accesses
Post by Andreas Hansson
Hi guys,
I am very much inclined to support Brad's approach, which doesn't care
about the "physical" topology of the interconnect.
Also, I don't want to de-rail the discussion, but an idea that I came
to think of based on all my previous NoC work, do you really need to
enquire the router network at all? Isn't the state always determined
what the controllers and end-points see? What happens if the network
only sees "packets" and has no clue about the actual higher-level
messages (which is the case in plenty real NoC implementations)?
There are several things that I believe you are missing out on.
* The claim that the network does not need to enquired at all is incorrect. It is
possible that the data is in some packet in the network, and hence the
network buffers need to be searched for that packet.
Secondly, it seems to me that the network hierarchy it self can store some
information that is required for making a functional access. I have not proven
this yet.
* A real NoC implementation does not support functional accesses. Anyway,
I am not assuming any particular structure on the packets themselves, except
that they provide a function for making a functional read/write access.
Changes have been made to the higher level messages to support those
functions.
* I have stated before that I am not opposed to having flat list of buffers. But
it is not the approach that I prefer.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Brad Beckmann
2012-10-08 17:32:51 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3558
-----------------------------------------------------------



src/mem/ruby/slicc_interface/RubySlicc_Util.hh
<http://reviews.gem5.org/r/1443/#comment3548>

What is going on here? Please add comments to these two functions.


- Brad Beckmann
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 3, 2012, 9:12 p.m.)
Review request for Default.
Description
-------
Changeset 9283:0da5f7f0cf48
---------------------------
ruby: augment network to support functional accesses
This patch adds support to ruby's network subsystem to support functional
accesses. This support exists for the simple network 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. In case of
the simple network, this entity is the Switch structure.
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
Nilay Vaish
2012-10-09 00:47:46 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------

(Updated Oct. 8, 2012, 5:47 p.m.)


Review request for Default.


Summary (updated)
-----------------

ruby: improved support for functional accesses


Description (updated)
-------

Changeset 9283:0f843ef51892
---------------------------
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 (updated)
-----

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
Brad Beckmann
2012-10-09 19:46:36 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3559
-----------------------------------------------------------


Thanks for the comments. This is much clearer. I only have one question below regarding the functional read logic.


src/mem/ruby/system/System.cc
<http://reviews.gem5.org/r/1443/#comment3549>

Is there any reason you try the read the message buffers in this order? Also have you given up on trying to check if only one Maybe_Stale copy exists? It appears so, otherwise I would have expected you to check for a Maybe_Stale copy after going through all the message buffers.


- Brad Beckmann
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 8, 2012, 5:47 p.m.)
Review request for Default.
Description
-------
Changeset 9283:0f843ef51892
---------------------------
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
Nilay Vaish
2012-10-09 20:18:46 UTC
Permalink
Post by Nilay Vaish
src/mem/ruby/system/System.cc, line 501
<http://reviews.gem5.org/r/1443/diff/3/?file=30251#file30251line501>
Is there any reason you try the read the message buffers in this order? Also have you given up on trying to check if only one Maybe_Stale copy exists? It appears so, otherwise I would have expected you to check for a Maybe_Stale copy after going through all the message buffers.
There is no particular order in which the buffers are read. In fact,
I don't even know the order in which the vector holds all the controllers.
That comment is not be interpreted as specifying some particular order.

For that maybe_stale case, I would prefer a solution in which we can
guarantee that functional reads always succeed. I will probably do that
as a separate patch, some time later.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3559
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 8, 2012, 5:47 p.m.)
Review request for Default.
Description
-------
Changeset 9283:0f843ef51892
---------------------------
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
Andreas Hansson
2012-10-11 07:50:23 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3561
-----------------------------------------------------------



src/mem/protocol/MESI_CMP_directory-L1cache.sm
<http://reviews.gem5.org/r/1443/#comment3551>

Very minor...the others just have a one-liner

return getCacheEntry(addr).DataBlk;

Perhaps stick to the same?



src/mem/protocol/MESI_CMP_directory-msg.sm
<http://reviews.gem5.org/r/1443/#comment3552>

A comment on what (or what is not) a coherence request of type PUTX?



src/mem/protocol/MESI_CMP_directory-msg.sm
<http://reviews.gem5.org/r/1443/#comment3553>

Why is it not symmetric with the reads?



src/mem/protocol/MESI_CMP_directory-msg.sm
<http://reviews.gem5.org/r/1443/#comment3554>

Same as previously, a short comment on why Data dataExclusive and memory data (what is data/mem data difference?).



src/mem/protocol/MESI_CMP_directory-msg.sm
<http://reviews.gem5.org/r/1443/#comment3555>

Again, why the asymmetry with reads?



src/mem/ruby/buffers/MessageBuffer.hh
<http://reviews.gem5.org/r/1443/#comment3556>

Why a pointer reference?



src/mem/ruby/buffers/MessageBuffer.hh
<http://reviews.gem5.org/r/1443/#comment3557>

a const pointer ref? Why?

Is it not possible that the write turns the packet into a response?



src/mem/ruby/buffers/MessageBuffer.cc
<http://reviews.gem5.org/r/1443/#comment3558>

Could this be iterators as well? Feels a bit off to mix counter based and iterator based iteration.



src/mem/ruby/buffers/MessageBuffer.cc
<http://reviews.gem5.org/r/1443/#comment3562>

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.



src/mem/ruby/network/Network.hh
<http://reviews.gem5.org/r/1443/#comment3559>

Not the same type as the other place...



src/mem/ruby/network/Network.hh
<http://reviews.gem5.org/r/1443/#comment3560>

Not the same type (was const Packet*&)



src/mem/ruby/network/simple/SimpleNetwork.cc
<http://reviews.gem5.org/r/1443/#comment3561>

now int and not size_t?

an iterator would be even nicer to see



src/mem/ruby/slicc_interface/RubyRequest.cc
<http://reviews.gem5.org/r/1443/#comment3563>

Just a note on the memtester...it is as far as I am concerned broken in its current implementation. The way it interacts with the shadow memory is too restrictive. The ordering model allows many more legal permutations than what we currently do by comparing with the functional memory.

I'm not sure I would design for a broken memtest to pass.


- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 8, 2012, 5:47 p.m.)
Review request for Default.
Description
-------
Changeset 9283:0f843ef51892
---------------------------
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
Nilay Vaish
2012-10-11 10:40:54 UTC
Permalink
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 83
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line83>
Why is it not symmetric with the reads?
While a check can be added in functionalWrite(), it is not necessary. The cases in which
the data block may not exist (from an actual physical implementation prespective), the
protocol will not read the data that a functionalWrite() may write to the block.

But that's not true for a functionalRead(). The data block is present in all the
messages, but only a few of them hold the actual data. Hence, the check is required.
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 75
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line75>
A comment on what (or what is not) a coherence request of type PUTX?
A comment on what is a PUTX appears with its definition.
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 98
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line98>
Same as previously, a short comment on why Data dataExclusive and memory data (what is data/mem data difference?).
There should be comments about these message types where they are defined.
But those comments are not helpful. I am editing those so that differentiation
can be made between types.
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 110
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line110>
Again, why the asymmetry with reads?
Same comment as above.
Post by Nilay Vaish
src/mem/ruby/buffers/MessageBuffer.hh, line 152
<http://reviews.gem5.org/r/1443/diff/3/?file=30232#file30232line152>
Why a pointer reference?
This is a mistake on my part.
Post by Nilay Vaish
src/mem/ruby/buffers/MessageBuffer.hh, line 158
<http://reviews.gem5.org/r/1443/diff/3/?file=30232#file30232line158>
a const pointer ref? Why?
Is it not possible that the write turns the packet into a response?
I am removing the reference.
Post by Nilay Vaish
src/mem/ruby/buffers/MessageBuffer.cc, line 451
<http://reviews.gem5.org/r/1443/diff/3/?file=30233#file30233line451>
Could this be iterators as well? Feels a bit off to mix counter based and iterator based iteration.
I am not a fan of iterators. But my knowledge of C++ tells me that map and list
datatypes do not support counter based traversal. With vectors, I tend to do
counter based traversal only.
Post by Nilay Vaish
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.
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.
Post by Nilay Vaish
src/mem/ruby/slicc_interface/RubyRequest.cc, line 28
<http://reviews.gem5.org/r/1443/diff/3/?file=30245#file30245line28>
Just a note on the memtester...it is as far as I am concerned broken in its current implementation. The way it interacts with the shadow memory is too restrictive. The ordering model allows many more legal permutations than what we currently do by comparing with the functional memory.
I'm not sure I would design for a broken memtest to pass.
I would not say memtest is broken, but I agree that it is restrictive.
Since one of the purposes of the patch is to clear the regression tests,
I have to produce code that would satisfy the tester. As and when the
tester is changed, I would redo the implementation to take care of the
changes.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3561
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 8, 2012, 5:47 p.m.)
Review request for Default.
Description
-------
Changeset 9283:0f843ef51892
---------------------------
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
Andreas Hansson
2012-10-11 16:26:26 UTC
Permalink
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 83
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line83>
Why is it not symmetric with the reads?
While a check can be added in functionalWrite(), it is not necessary. The cases in which
the data block may not exist (from an actual physical implementation prespective), the
protocol will not read the data that a functionalWrite() may write to the block.
But that's not true for a functionalRead(). The data block is present in all the
messages, but only a few of them hold the actual data. Hence, the check is required.
Could you add a few lines along these lines in the code? In short: Why is the check for PUTX and nothing else for the read, and why no check for the write.
Post by Nilay Vaish
src/mem/protocol/MESI_CMP_directory-msg.sm, line 98
<http://reviews.gem5.org/r/1443/diff/3/?file=30215#file30215line98>
Same as previously, a short comment on why Data dataExclusive and memory data (what is data/mem data difference?).
There should be comments about these message types where they are defined.
But those comments are not helpful. I am editing those so that differentiation
can be made between types.
I was more asking for a line or two in the code describing why these are the ones in the if statement. Could you add this?
Post by Nilay Vaish
src/mem/ruby/buffers/MessageBuffer.cc, line 451
<http://reviews.gem5.org/r/1443/diff/3/?file=30233#file30233line451>
Could this be iterators as well? Feels a bit off to mix counter based and iterator based iteration.
I am not a fan of iterators. But my knowledge of C++ tells me that map and list
datatypes do not support counter based traversal. With vectors, I tend to do
counter based traversal only.
I'll live with it :) until we go c++11 and can make it a for (auto s: m_prio_heap)
Post by Nilay Vaish
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.
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.
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.
Post by Nilay Vaish
src/mem/ruby/slicc_interface/RubyRequest.cc, line 28
<http://reviews.gem5.org/r/1443/diff/3/?file=30245#file30245line28>
Just a note on the memtester...it is as far as I am concerned broken in its current implementation. The way it interacts with the shadow memory is too restrictive. The ordering model allows many more legal permutations than what we currently do by comparing with the functional memory.
I'm not sure I would design for a broken memtest to pass.
I would not say memtest is broken, but I agree that it is restrictive.
Since one of the purposes of the patch is to clear the regression tests,
I have to produce code that would satisfy the tester. As and when the
tester is changed, I would redo the implementation to take care of the
changes.
I still think there is a danger designing for a test which is not really testing what it should be testing (i.m.h.o), but I'm happy to go ahead as you suggest.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3561
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
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
Nilay Vaish
2012-10-15 20:58:56 UTC
Permalink
Post by Nilay Vaish
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.
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.
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
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
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
Nilay Vaish
2012-10-11 10:47:56 UTC
Permalink
-----------------------------------------------------------
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 (updated)
-------

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 (updated)
-----

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
Nilay Vaish
2012-10-15 21:15:20 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------

(Updated Oct. 15, 2012, 2:15 p.m.)


Review request for Default.


Description (updated)
-------

Changeset 9302:f07b94c9f16e
---------------------------
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 (updated)
-----

configs/example/ruby_mem_test.py 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-L1cache.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-L2cache.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-dir.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-msg.sm 0b9fcd304b58
src/mem/protocol/MI_example-cache.sm 0b9fcd304b58
src/mem/protocol/MI_example-dir.sm 0b9fcd304b58
src/mem/protocol/MI_example-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-L1cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-L1cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-msg.sm 0b9fcd304b58
src/mem/protocol/Network_test-msg.sm 0b9fcd304b58
src/mem/protocol/RubySlicc_Exports.sm 0b9fcd304b58
src/mem/protocol/RubySlicc_MemControl.sm 0b9fcd304b58
src/mem/ruby/buffers/MessageBuffer.hh 0b9fcd304b58
src/mem/ruby/buffers/MessageBuffer.cc 0b9fcd304b58
src/mem/ruby/buffers/MessageBufferNode.hh 0b9fcd304b58
src/mem/ruby/network/Network.hh 0b9fcd304b58
src/mem/ruby/network/simple/PerfectSwitch.cc 0b9fcd304b58
src/mem/ruby/network/simple/SimpleNetwork.hh 0b9fcd304b58
src/mem/ruby/network/simple/SimpleNetwork.cc 0b9fcd304b58
src/mem/ruby/network/simple/Switch.hh 0b9fcd304b58
src/mem/ruby/network/simple/Switch.cc 0b9fcd304b58
src/mem/ruby/slicc_interface/AbstractController.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/Message.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/NetworkMessage.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/RubyRequest.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/RubyRequest.cc 0b9fcd304b58
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 0b9fcd304b58
src/mem/ruby/system/MemoryControl.hh 0b9fcd304b58
src/mem/ruby/system/MemoryControl.cc 0b9fcd304b58
src/mem/ruby/system/RubyMemoryControl.hh 0b9fcd304b58
src/mem/ruby/system/RubyMemoryControl.cc 0b9fcd304b58
src/mem/ruby/system/System.cc 0b9fcd304b58
src/mem/slicc/ast/TypeDeclAST.py 0b9fcd304b58
src/mem/slicc/symbols/StateMachine.py 0b9fcd304b58
src/mem/slicc/symbols/SymbolTable.py 0b9fcd304b58
src/mem/slicc/symbols/Type.py 0b9fcd304b58

Diff: http://reviews.gem5.org/r/1443/diff/


Testing
-------


Thanks,

Nilay Vaish
Andreas Hansson
2012-10-15 21:34:54 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1443/#review3581
-----------------------------------------------------------

Ship it!


Ship It!

- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1443/
-----------------------------------------------------------
(Updated Oct. 15, 2012, 2:15 p.m.)
Review request for Default.
Description
-------
Changeset 9302:f07b94c9f16e
---------------------------
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 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-L1cache.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-L2cache.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-dir.sm 0b9fcd304b58
src/mem/protocol/MESI_CMP_directory-msg.sm 0b9fcd304b58
src/mem/protocol/MI_example-cache.sm 0b9fcd304b58
src/mem/protocol/MI_example-dir.sm 0b9fcd304b58
src/mem/protocol/MI_example-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-L1cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-L2cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_directory-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-L1cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_CMP_token-msg.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-cache.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-dir.sm 0b9fcd304b58
src/mem/protocol/MOESI_hammer-msg.sm 0b9fcd304b58
src/mem/protocol/Network_test-msg.sm 0b9fcd304b58
src/mem/protocol/RubySlicc_Exports.sm 0b9fcd304b58
src/mem/protocol/RubySlicc_MemControl.sm 0b9fcd304b58
src/mem/ruby/buffers/MessageBuffer.hh 0b9fcd304b58
src/mem/ruby/buffers/MessageBuffer.cc 0b9fcd304b58
src/mem/ruby/buffers/MessageBufferNode.hh 0b9fcd304b58
src/mem/ruby/network/Network.hh 0b9fcd304b58
src/mem/ruby/network/simple/PerfectSwitch.cc 0b9fcd304b58
src/mem/ruby/network/simple/SimpleNetwork.hh 0b9fcd304b58
src/mem/ruby/network/simple/SimpleNetwork.cc 0b9fcd304b58
src/mem/ruby/network/simple/Switch.hh 0b9fcd304b58
src/mem/ruby/network/simple/Switch.cc 0b9fcd304b58
src/mem/ruby/slicc_interface/AbstractController.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/Message.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/NetworkMessage.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/RubyRequest.hh 0b9fcd304b58
src/mem/ruby/slicc_interface/RubyRequest.cc 0b9fcd304b58
src/mem/ruby/slicc_interface/RubySlicc_Util.hh 0b9fcd304b58
src/mem/ruby/system/MemoryControl.hh 0b9fcd304b58
src/mem/ruby/system/MemoryControl.cc 0b9fcd304b58
src/mem/ruby/system/RubyMemoryControl.hh 0b9fcd304b58
src/mem/ruby/system/RubyMemoryControl.cc 0b9fcd304b58
src/mem/ruby/system/System.cc 0b9fcd304b58
src/mem/slicc/ast/TypeDeclAST.py 0b9fcd304b58
src/mem/slicc/symbols/StateMachine.py 0b9fcd304b58
src/mem/slicc/symbols/SymbolTable.py 0b9fcd304b58
src/mem/slicc/symbols/Type.py 0b9fcd304b58
Diff: http://reviews.gem5.org/r/1443/diff/
Testing
-------
Thanks,
Nilay Vaish
Loading...