Discussion:
[gem5-dev] Review Request 2276: ruby: don't make O3 CPU squash on loads that hit outstanding requests
Steve Reinhardt via gem5-dev
2014-05-14 05:47:05 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------

Review request for Default.


Repository: gem5


Description
-------

Changeset 10228:f377969aa1b2
---------------------------
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.


Diffs
-----

src/mem/ruby/system/Sequencer.hh 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
src/mem/ruby/system/Sequencer.cc 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f

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


Testing
-------


Thanks,

Steve Reinhardt
Nilay Vaish via gem5-dev
2014-05-14 13:41:15 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/#review5094
-----------------------------------------------------------


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

- Nilay Vaish
Post by Steve Reinhardt via gem5-dev
-----------------------------------------------------------
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------
(Updated May 14, 2014, 5:47 a.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 10228:f377969aa1b2
---------------------------
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.
Diffs
-----
src/mem/ruby/system/Sequencer.hh 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
src/mem/ruby/system/Sequencer.cc 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
Diff: http://reviews.gem5.org/r/2276/diff/
Testing
-------
Thanks,
Steve Reinhardt
Steve Reinhardt via gem5-dev
2014-05-14 14:47:53 UTC
Permalink
Post by Steve Reinhardt via gem5-dev
Post by Nilay Vaish via gem5-dev
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();
Nilay, can you provide some more context? All the quick regressions ran for me (though of course the stats changed).


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/#review5094
-----------------------------------------------------------
Post by Steve Reinhardt via gem5-dev
-----------------------------------------------------------
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------
(Updated May 13, 2014, 10:47 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 10228:f377969aa1b2
---------------------------
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.
Diffs
-----
src/mem/ruby/system/Sequencer.hh 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
src/mem/ruby/system/Sequencer.cc 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
Diff: http://reviews.gem5.org/r/2276/diff/
Testing
-------
Thanks,
Steve Reinhardt
Nilay Vaish via gem5-dev
2014-05-15 21:43:16 UTC
Permalink
Post by Steve Reinhardt via gem5-dev
Post by Nilay Vaish via gem5-dev
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();
Nilay, can you provide some more context? All the quick regressions ran for me (though of course the stats changed).
I am guessing you tested with all the patches applied. When I applied
just this patch and tried to boot Linux, I got the segmentation fault.

--
Nilay
Steve Reinhardt via gem5-dev
2014-05-17 03:53:24 UTC
Permalink
Post by Nilay Vaish via gem5-dev
I am guessing you tested with all the patches applied. When I applied
just this patch and tried to boot Linux, I got the segmentation fault.
Actually I did test most of the patches individually, I think including
this one. I chatted with Marc Orr and think I found the problem: he had a
separate patch to fix the bug you're seeing, but I didn't see a point in
keeping it separate, so I merged it before posting these... but ended up
merging it with the wrong patch (2277 instead of 2276). I'll try to go
back and fix it, but in the mean time you will have to apply both 2276 and
2277 for testing.

Steve
Steve Reinhardt via gem5-dev
2014-05-21 00:15:44 UTC
Permalink
Hi Nilay,

I cannot reproduce this failure. The only regression test for
X86_MESI_Two_Level uses a simple timing CPU, so that passes OK, as do all
the other regressions, even when this is the only patch applied. I tried
this command line:

build/X86_MESI_Two_Level/gem5.opt configs/example/fs.py
--cpu-type=detailed --caches --ruby

and the simulation appears to hang after printing this on the console:

ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading
namespace from ACPI tables [20070126]
ACPI: Unable to load the System Description Tables

but I do not get a segfault as you have indicated. Can you tell me exactly
what command line you were using to observe the error?

Thanks,

Steve
Post by Steve Reinhardt via gem5-dev
Post by Nilay Vaish via gem5-dev
I am guessing you tested with all the patches applied. When I applied
just this patch and tried to boot Linux, I got the segmentation fault.
Actually I did test most of the patches individually, I think including
this one. I chatted with Marc Orr and think I found the problem: he had a
separate patch to fix the bug you're seeing, but I didn't see a point in
keeping it separate, so I merged it before posting these... but ended up
merging it with the wrong patch (2277 instead of 2276). I'll try to go
back and fix it, but in the mean time you will have to apply both 2276 and
2277 for testing.
Steve
Nilay Vaish via gem5-dev
2014-05-21 01:22:02 UTC
Permalink
diff -r 9eab5efc02e8 tests/configs/pc-simple-timing-ruby.py
--- a/tests/configs/pc-simple-timing-ruby.py Fri May 09 18:58:50 2014
-0400
+++ b/tests/configs/pc-simple-timing-ruby.py Tue May 20 20:19:57 2014
-0500
@@ -65,7 +65,7 @@
voltage_domain =
system.voltage_domain)
system.cpu_clk_domain = SrcClockDomain(clock = '2GHz',
voltage_domain =
system.voltage_domain)
-system.cpu = [TimingSimpleCPU(cpu_id=i, clk_domain =
system.cpu_clk_domain)
+system.cpu = [DerivO3CPU(cpu_id=i, clk_domain = system.cpu_clk_domain)
for i in xrange(options.num_cpus)]

Ruby.create_system(options, system, system.iobus, system._dma_ports)

----------------------------------------------------------------------

I made the following change to the config file for the fs regression test.
After that I just ran the command line from the simout file for this
regression test.

--
Nilay
Post by Steve Reinhardt via gem5-dev
Hi Nilay,
I cannot reproduce this failure. The only regression test for
X86_MESI_Two_Level uses a simple timing CPU, so that passes OK, as do all
the other regressions, even when this is the only patch applied. I tried
build/X86_MESI_Two_Level/gem5.opt configs/example/fs.py
--cpu-type=detailed --caches --ruby
ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading
namespace from ACPI tables [20070126]
ACPI: Unable to load the System Description Tables
but I do not get a segfault as you have indicated. Can you tell me exactly
what command line you were using to observe the error?
Thanks,
Steve
Andreas Hansson via gem5-dev
2014-05-15 22:31:02 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/#review5104
-----------------------------------------------------------



src/mem/ruby/system/Sequencer.cc
<http://reviews.gem5.org/r/2276/#comment4622>

Not sure what your thoughts are, but using "auto" would clean it up quite a bit (here and other places in the file).


- Andreas Hansson
Post by Steve Reinhardt via gem5-dev
-----------------------------------------------------------
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------
(Updated May 14, 2014, 5:47 a.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 10228:f377969aa1b2
---------------------------
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.
Diffs
-----
src/mem/ruby/system/Sequencer.hh 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
src/mem/ruby/system/Sequencer.cc 34f48d0dac97d04f3d1e129a1f4aa00d869b1d8f
Diff: http://reviews.gem5.org/r/2276/diff/
Testing
-------
Thanks,
Steve Reinhardt
Steve Reinhardt via gem5-dev
2014-06-21 17:00:19 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------

(Updated June 21, 2014, 10 a.m.)


Review request for Default.


Changes
-------

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.


Repository: gem5


Description (updated)
-------

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.


Diffs (updated)
-----

src/mem/packet.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/protocol/RubySlicc_Exports.sm b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/DMASequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/DMASequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPort.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPort.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPortProxy.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPortProxy.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/Sequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/Sequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1

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


Testing
-------


Thanks,

Steve Reinhardt
Emilio Castillo via gem5-dev
2014-08-28 12:39:07 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2276/#review5314
-----------------------------------------------------------



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.

- Emilio Castillo
Post by Steve Reinhardt via gem5-dev
-----------------------------------------------------------
http://reviews.gem5.org/r/2276/
-----------------------------------------------------------
(Updated June 21, 2014, 5 p.m.)
Review request for Default.
Repository: gem5
Description
-------
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.
Diffs
-----
src/mem/packet.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/protocol/RubySlicc_Exports.sm b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/DMASequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/DMASequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPort.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPort.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPortProxy.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/RubyPortProxy.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/Sequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
src/mem/ruby/system/Sequencer.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
Diff: http://reviews.gem5.org/r/2276/diff/
Testing
-------
Thanks,
Steve Reinhardt
Loading...