Thanks for that patch Brad. Joe, one of our M5 students, had told me about changing that earlier so it's at least we know that we are viewing the same issues on our side at UM.
However, shouldn't that variable be changed from "deadlock_threshold" to "livelock_threshold" or "starvation_threshold"? Because, by definition, if you can wait a certain # of cycles to resolve a contention scenario, then it's not a deadlock. Deadlock would be there are no more events to be processed and the simulation stops (because everyone is waiting for some event that is never to come). It seems, there is some kind of starvation scenario that's happening here that we are flagging. There is a similar flag somewhere in M5 for detecting if you are repeatedly cycling on load-locked/store-conditionals if memory serves correct but any case that parameter may be a bit of a misnomer... On Mon, Feb 7, 2011 at 1:39 PM, Nilay Vaish <ni...@cs.wisc.edu> 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 > -- - Korey
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
