-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3181/#review7446
-----------------------------------------------------------


Overall, this looks alright. I'd prefer that the Invalidate name change is 
removed from this patch, though.


src/cpu/o3/lsq_unit.hh (line 955)
<http://reviews.gem5.org/r/3181/#comment6287>

    Do packets need to be deleted when sendStoreAccess() fails (here and line 
971)?



src/mem/packet.hh (line 129)
<http://reviews.gem5.org/r/3181/#comment6286>

    This name change doesn't appear to be necessary. Can you please remove it, 
or move it to a separate review request?


- Joel Hestness


On Oct. 30, 2015, 9:50 p.m., Tony Gutierrez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3181/
> -----------------------------------------------------------
> 
> (Updated Oct. 30, 2015, 9:50 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11187:e5e740fac1fb
> ---------------------------
> cpu: Add store-access operations
> 
> This patch was created by Bihn Pham during his internship at AMD.
> 
> This patch adds decoupled store operations that are commonly used by
> high-performance processors. The patch modifies the O3 CPU model to issue
> StoreAccess operations as soon as possible to acquire exclusive permission for
> eventual stores. Later data store operations behave as normal.
> 
> In the classic memory model, StoreAccess requests are treated as HardPFExReq
> and share the existing prefetch queue. Therefore, they affect performance only
> if the prefetcher is enabled in the classic model.
> 
> In Ruby, StoreAccess requests are treated as RubyStore with NULL data field.
> 
> 
> Diffs
> -----
> 
>   src/cpu/o3/lsq_unit.hh 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/cpu/o3/lsq_unit_impl.hh 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/abstract_mem.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/cache/cache.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/cache/mshr.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/cache/prefetch/queued.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/packet.hh 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/packet.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/protocol/RubySlicc_Exports.sm 
> 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/ruby/system/RubyPort.hh 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/ruby/system/RubyPort.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
>   src/mem/ruby/system/Sequencer.cc 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 
> 
> Diff: http://reviews.gem5.org/r/3181/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to