Any new insights on what happens?
Le 12/06/2012 16:20, Nathanaël Prémillieu a écrit :
Ok, my bad.
The new trace:
http://www.irisa.fr/alf/downloads/premillieu/gem5/445.gobmk.score2.trace_All-Event.deferredtime.gz
The code look like that now:
// if we have a response packet waiting we have to start with that
if (deferredPacketReady()) {
// use the normal approach from the timing port
trySendTiming();
DPRINTF(Cache, "Got deferred packet ready\n");
} else {
DPRINTF(Cache, "Deferred packet is not ready (time: %d)\n",
deferredPacketReadyTime());
// check for request packets (requests & writebacks)
PacketPtr pkt = cache.getTimingPacket();
if (pkt == NULL) {
// can happen if e.g. we attempt a writeback and fail, but
// before the retry, the writeback is eliminated because
// we snoop another cache's ReadEx.
waitingOnRetry = false;
DPRINTF(Cache, "Deferred packet is null\n");
Nathanaël
Le 12/06/2012 14:22, Andreas Hansson a écrit :
Thanks. Actually I was thinking of the other branch, i.e. have the
ReadyTime printed in the else part to find out if something is waiting
but not ready.
Andreas
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Nathanaël Prémillieu
Sent: 12 June 2012 12:50
To: [email protected]
Subject: Re: [gem5-users] Bpred: RAS maybe not getting correctly
squashed (in some case)
A new trace with the deferredPacketReadyTime() information:
http://www.irisa.fr/alf/downloads/premillieu/gem5/445.gobmk.score2.trace_All-Event.withtime.gz
The DPRINTF is now DPRINTF(Cache, "Got deferred packet ready (time:
%d)\n", deferredPacketReadyTime());
Nathanaël
Le 12/06/2012 10:49, Andreas Hansson a écrit :
It seems there is no response waiting (or at least not ready). Is
there any chance you could also add a deferredPacketReadyTime() to
the DPRINTF just to find out if there is actually something waiting
(and just not ready)?
Andreas
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Nathanaël Prémillieu
Sent: 11 June 2012 21:59
To: [email protected]
Subject: Re: [gem5-users] Bpred: RAS maybe not getting correctly
squashed (in some case)
Here is a new trace with more output before and after:
http://www.irisa.fr/alf/downloads/premillieu/gem5/445.gobmk.score2.trace_All-Event.gz
The DPRINT statement is DPRINTF(Cache, "Got deferred packet ready\n");
Nathanaël
Le 11/06/2012 18:33, Nathanaël Prémillieu a écrit :
I use the arm_detailed cpu model with no modification to the cpu
configuration. Here is the option I give to the se.py script:
--cpu-type=arm_detailed --caches --l2cache
--checkpoint-dir=/temp_dd/alf_2/npremill/spec2006/checkpoints/base/445.gobmk/cpt.gobmk.ref.score2
--checkpoint-restore=200875000000 --at-instruction -m 1000000 -W
25000000 --standard-switch -c
/local/npremill/test_gen3.445.gobmk.score2.14.2009/gobmk_base.armv7_nothumb-gcc
--input=score2.tst -o "--quiet --mode gtp" --output=score2.out
--errout=score2.err
The only modification I have made to the se.py script is to have a
physical memory of 2048MB instead of 512MB.
I have put the DPRINT statement in the code. I will send the trace
output once the run is done.
Le 11/06/2012 18:06, Ali Saidi a écrit :
Well, the good news is that it should'n be too hard to debug as it's
just looping and not making any progress. The bad news is I can only
make some guesses from the trace. It appears as though the L2 cache is
blocked (out of MSHRs). At least some of these responses are coming
from
the L1 cache (responses to prefetcher requests that hit in the L1
icache). However, for reasons I'm not sure about the L1 seems to be
sending a demand request and not the responses. That isn't supposed to
happen. How many MSHRs does your L2 have? Can you put a DPRINT in the
cache and see if you get into the deferredPacketReady if statement?
if (deferredPacketReady()) {
// use the normal approach from the timing port
trySendTiming();
} else {
Thanks,
Ali
On 11.06.2012 11:06, Nathanaël Prémillieu wrote:
The trace continues with the same lines again and again. I have
waited
for the simulator to finish for more than one day but it is in this
infinite loop retrying to do the access.
Nathanaël
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
