ruby: don't make O3 CPU squash on loads that hit outstanding requests
Review Request #2276 - Created May 13, 2014 and discarded
| Information | |
|---|---|
| Steve Reinhardt | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10240:b01d667ec431 --------------------------- ruby: don't make O3 CPU squash on loads that hit outstanding requests Mismatch between O3 and Ruby in handling aliased requests: Ruby returns false when it sees aliased request or memory blocked. O3 squash and refetch when it sees false signal from Ruby. Fix: Merging readRequestTable and writeRequestTable in a single table that maps requesting address and all requests that are aliased with the address. This work was done while Binh was an intern at AMD Research.
Issue Summary
2
1
1
0
| Description | From | Last Updated | Status |
|---|---|---|---|
| initialize to false? | Nilay Vaish | Dec. 4, 2014, 7:36 a.m. | Open |
Posted (May 14, 2014, 6:41 a.m.)
gem5 aborts due to segmentation fault with this patch applied.
Program received signal SIGSEGV, Segmentation fault.
Sequencer::writeCallback (this=0x3c9d800, address=..., data=..., externalHit=false, mach=MachineType_NUM, initialRequestTime=..., forwardRequestTime=..., firstResponseTime=...)
at build/X86_MESI_Two_Level/mem/ruby/system/Sequencer.cc:407
407 request = i->second->front();
Posted (May 15, 2014, 3:31 p.m.)
-
src/mem/ruby/system/Sequencer.cc (Diff revision 1) -
Not sure what your thoughts are, but using "auto" would clean it up quite a bit (here and other places in the file).
Review request changed
Updated (June 21, 2014, 10 a.m.)
Change Summary:
Fixed bug that Nilay found, which arose when an ifetch got issued between the load and store parts of a locked RMW. The ifetch qould issue, but the first thing it does is try to invalidate the block out of the L1D cache to move to the L1I cache, and since the block was locked, the cache would deadlock. Now we explicitly track when a request has locked a block and defer any access that is not an unlock request. The O3 boot test Nilay was running now passes, with the addition of the patch at http://reviews.gem5.org/r/2302. Did some substantial cleanup on this patch in the process.
Description: |
|
||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+235 -302) |
Posted (Aug. 28, 2014, 5:39 a.m.)
This patch seems to be interfering with the ruby drain functionality, I have tried a switch cpu from the timing to the detailed cpu model and the draining of the Sequencer will not end. I believe that the issue is related to the number of outstanding requests not being updated properly.
Posted (Dec. 4, 2014, 7:36 a.m.)
Steve, is it all right to buffer requests in the Sequencer? I am not even in favor of having a sequencer and buffering requests makes it worse.
-
src/mem/ruby/system/Sequencer.cc (Diff revision 2) -
initialize to false?