Nilay,
If the same test completes with larger threshold then it
certainly a case of false positive and certainly NOT a deadlock (but may
be a case of starvation). If it were actually a deadlock, it would have
just reported deadlock after some more time of simulation.
On extending stall and wait to other protocols, you are absolutely
correct. Many of the starvation issues (and thus perceived deadlock)
show up due to "unfairness" in handling coherence request. After the
protocol trace segmentation issue is solved, I can get
MESI_CMP_directory to use stall and wait.
I fully agree with Brad's argument about bumping up threshold for
testers. And having large threshold (i.e. 5 M) does not hurt much. It
will take bit more time of simulation to report the deadlock, but if
there is an actual deadlock it would anyway report it. So I would vote
to stick with Brad's threshold number in the patch.
Thanks
Arka
On 02/07/2011 12:39 PM, Nilay Vaish wrote:
Brad,
I think 5,000,000 is a lot. IIRC, a million worked the last time I
tested the protocol. We can check the patch in, though I am of the
view that we should let it remain as is till we can generate the
protocol trace and make sure that this not an actual dead lock. I need
to first detect the reason for the segmentation fault received only
when trace is being collected.
Another issue is that we need to extend the stall and wait to other
protocols as well. This, I believe, may help in reducing such deadlock
instances. While working on MESI CMP, I saw many of the times earlier
requests remain un-fulfilled because of later requests for the same
address.
--
Nilay
On Mon, 7 Feb 2011, Beckmann, Brad wrote:
Yep, if I increase the deadlock threshold to 5 million cycles, the
deadlock warning is not encountered. However, I don't think that we
should increase the default deadlock threshold to by an
order-of-magnitude. Instead, let's just increase the threashold for
the mem tester. How about I check in the following small patch.
Brad
diff --git a/configs/example/ruby_mem_test.py
b/configs/example/ruby_mem_test.py
--- a/configs/example/ruby_mem_test.py
+++ b/configs/example/ruby_mem_test.py
@@ -135,6 +135,12 @@
cpu.test = system.ruby.cpu_ruby_ports[i].port
cpu.functional = system.funcmem.port
+ #
+ # Since the memtester is incredibly bursty, increase the deadlock
+ # threshold to 5 million cycles
+ #
+ system.ruby.cpu_ruby_ports[i].deadlock_threshold = 5000000
+
for (i, dma) in enumerate(dmas):
#
# Tie the dma memtester ports to the correct functional port
diff --git a/tests/configs/memtest-ruby.py
b/tests/configs/memtest-ruby.py
--- a/tests/configs/memtest-ruby.py
+++ b/tests/configs/memtest-ruby.py
@@ -96,6 +96,12 @@
#
cpus[i].test = ruby_port.port
cpus[i].functional = system.funcmem.port
+
+ #
+ # Since the memtester is incredibly bursty, increase the deadlock
+ # threshold to 5 million cycles
+ #
+ ruby_port.deadlock_threshold = 5000000
# -----------------------
# run simulation
-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Monday, February 07, 2011 9:12 AM
To: M5 Developer List
Subject: Re: [m5-dev] changeset in m5: Ruby: Fixes MESI CMP directory
protocol
Brad, I also see the protocol getting into a dead lock. I tried to
get a trace, but
I get segmentation fault (yes, the segmentation fault only occurs
when trace
flag ProtocolTrace is supplied). It seems to me that memory is getting
corrupted somewhere, because the fault occurs in malloc it self.
It could be that protocol is actually not in a dead lock. Both Arka
and I had
increased the deadlock threashold while testing the protocol. I will
try with
increased threashold later in the day.
One more thing, the Orion 2.0 code that was committed last night
makes use
of printf(). It did not compile cleanly for me. I had change it
fatal() and include
the header file base/misc.hh.
--
Nilay
On Mon, 7 Feb 2011, Beckmann, Brad wrote:
FYI...If my local regression tests are correct. This patch does not
fix all the problems with the MESI_CMP_directory protocol. One of the
patches I just checked in fixes a subtle bug in the ruby_mem_test.
Fixing this bug, exposes more deadlock problems in the
MESI_CMP_directory protocol.
To reproduce the regression tester's sequencer deadlock error, set the
Randomization flag to false in the file
configs/example/ruby_mem_test.py then run the following command:
build/ALPHA_SE_MESI_CMP_directory/m5.debug
configs/example/ruby_mem_test.py -n 8
Let me know if you have any questions,
Brad
-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-
boun...@m5sim.org] On
Behalf Of Nilay Vaish
Sent: Thursday, January 13, 2011 8:50 PM
To: m5-dev@m5sim.org
Subject: [m5-dev] changeset in m5: Ruby: Fixes MESI CMP directory
protocol
changeset 8f37a23e02d7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8f37a23e02d7
description:
Ruby: Fixes MESI CMP directory protocol
The current implementation of MESI CMP directory protocol is
broken.
This patch, from Arkaprava Basu, fixes the protocol.
diffstat:
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
