This was real quick!
--
Nilay
On Fri, 18 Nov 2011, Brad Beckmann wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/894/#review1666
-----------------------------------------------------------
src/mem/protocol/MESI_CMP_directory-L1cache.sm
<http://reviews.m5sim.org/r/894/#comment2157>
Change name to send_evictions
src/mem/protocol/MI_example-cache.sm
<http://reviews.m5sim.org/r/894/#comment2158>
Same here
src/mem/protocol/MOESI_CMP_directory-L1cache.sm
<http://reviews.m5sim.org/r/894/#comment2159>
and here
src/mem/protocol/MOESI_CMP_token-L1cache.sm
<http://reviews.m5sim.org/r/894/#comment2160>
here
src/mem/protocol/MOESI_hammer-cache.sm
<http://reviews.m5sim.org/r/894/#comment2161>
here
src/mem/protocol/RubySlicc_Types.sm
<http://reviews.m5sim.org/r/894/#comment2162>
Change name to evictionCallback
src/mem/ruby/system/RubyPort.cc
<http://reviews.m5sim.org/r/894/#comment2163>
ruby_eviction_callback
src/mem/ruby/system/Sequencer.hh
<http://reviews.m5sim.org/r/894/#comment2164>
Again evictionCallback
- Brad
On 2011-11-18 15:33:07, Nilay Vaish wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/894/
-----------------------------------------------------------
(Updated 2011-11-18 15:33:07)
Review request for Default.
Summary
-------
O3, Ruby: Forward invalidations from Ruby to O3 CPU
This patch implements the functionality for forwarding invalidations and
replacements from the L1 cache of the Ruby memory system to the O3 CPU. The
implementation adds a list of ports to RubyPort. Whenever a replacement or an
invalidation is performed, the L1 cache forwards this to all the ports, which
I believe is the LSQ in case of the O3 CPU. Those who understand the O3 LSQ
should take a close look at the implementation and figure out (at least
qualitatively) if some thing is missing or erroneous.
A couple of issues that need discussion --
* How to avoid deadlock in the O3 CPU? The CPU may not be able to proceed if a
particularly cache block is repeatedly invalidated before the CPU can retire
the actual load/store instruction. How do we ensure that at least one
instruction is retired before an invalidation/replacement is processed?
* How to test this implementation? Is it possible to implement some of the
tests that we regularly come across in papers on consistency models? Or those
present in manuals from AMD and Intel? I have tested that Ruby will forward
the invalidations, but not the part where the LSQ needs to act on it.
Diffs
-----
configs/example/se.py 330f8109b199
configs/ruby/MESI_CMP_directory.py 330f8109b199
configs/ruby/MI_example.py 330f8109b199
configs/ruby/MOESI_CMP_directory.py 330f8109b199
configs/ruby/MOESI_CMP_token.py 330f8109b199
configs/ruby/MOESI_hammer.py 330f8109b199
src/mem/protocol/MESI_CMP_directory-L1cache.sm 330f8109b199
src/mem/protocol/MI_example-cache.sm 330f8109b199
src/mem/protocol/MOESI_CMP_directory-L1cache.sm 330f8109b199
src/mem/protocol/MOESI_CMP_token-L1cache.sm 330f8109b199
src/mem/protocol/MOESI_hammer-cache.sm 330f8109b199
src/mem/protocol/RubySlicc_Types.sm 330f8109b199
src/mem/ruby/system/RubyPort.hh 330f8109b199
src/mem/ruby/system/RubyPort.cc 330f8109b199
src/mem/ruby/system/Sequencer.hh 330f8109b199
src/mem/ruby/system/Sequencer.cc 330f8109b199
Diff: http://reviews.m5sim.org/r/894/diff
Testing
-------
Thanks,
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
