Also, in terms of debugging there are a couple of ways:
You could
use the checker CPU (look at the checker regression tests) which
combines a functional cpu and an o3 cpu into one. The functional CPU
checks the execution of the out-of-order cpu and can report issues as
they arise. Another method to debug the system is to take a checkpoint
before your benchmark starts and first make sure you can restore it into
the functional model and it works correctly. You can then use tracing
from that point (and in particular the -ExecKernel flag) to remove
kernel code from the execution trace and only look at the user code.
This combined with the tracediff script in the util directory can narrow
down the issue if the checker is unable to find it. FYI, there are some
instructions and events that can't be verified by the checker CPU, so
while it can catch many errors, it's possible that some will be missed
(e.g. an interrupt occurring at the correct time).
Lastly, there is
currently an issue with the configuration of the arm detailed CPU
getting into WFI and never leaving that is caused by the exact sequence
of ops in a WFI loop along with the enabling and disabling of
interrupts. It's possible that you've experienced this issue. It's a
rather annoying bug in which the exact parameters chosen express the
issue, but any slight perturbation and the issue goes away. If that is
the case the following diff might fix your issue, but it has problems
with the x86 architecture:
diff -r 300e526eb69b -r 8ab362e0829c
src/cpu/o3/commit_impl.hh
--- a/src/cpu/o3/commit_impl.hh Mon Dec 17
18:26:36 2012 +0000
+++ b/src/cpu/o3/commit_impl.hh Mon Dec 17 19:35:33
2012 +0000
@@ -1058,6 +1058,17 @@
"PC skip function event, stopping
commitn");
break;
}
+
+ // Check if an instruction just enabled
interrupts. In
+ // that case, squash younger instructions in the
+ //
pipeline and handle the interrupt on the next
+ // cycle. If we don't do
this, we might end up in a
+ // live lock situation where we enable
interrupts at
+ // the beginning of the commit cycle and disable them
+
// again before the cycle completes (interrupts are
+ // only handled at
the beginning of a commit cycle).
+ if (!interrupt &&
cpu->checkInterrupts(cpu->tcBase(0)))
+ squashAfter(tid, head_inst);
}
else {
DPRINTF(Commit, "Unable to commit head instruction PC:%s "
"[tid:%i] [sn:%i].n",
Ali
On 09.01.2013 09:03, Ali Saidi wrote:
>
Hi Orangaede,
>
> I've seen a v8 benchmark run successfully to
completion with the out-of-order model. That said it's possible that
some part of your configuration is hitting a corner case that is causing
issues. The various v8 benchmarks have different run times (i'm not sure
which one you're talking about) and I'm not sure which version of gem5
you're using. Depending on how you have it compiled the instruction rate
of the out-of-order cpu can be over 200kips, so this is a bit slower
than I would expect.
>
> Ali
>
> On Jan 9, 2013, at 8:46 AM, "Mr.
Orangeade" <[email protected]> wrote:
>
>> Hey guys,
>>
>> I'm
trying to run v8 benchmark (console) using gem5 (fs).
>> With the
functional model everything seems to be fine.
>> Benchmark was executed
correctly and I got all the required statistics in about 15 minutes or
so.
>> Then I wanted to switch to the performance model (arm_detailed)
but got some issues there.
>>
>> To estimate the running time I simply
divided the total number of simulated instructions I got from the
functional model by the performance model's instruction rate I got from
the different benchmark (around 50k/s). That shouldn't be absolutely
correct but seems to be enough to get some estimation.
>>
>> This
calculation gave me the running time around 24 hours which is fine.
>>
Unfortunately around 2 weeks already passed but the benchmark didn't
finish yet.
>> It seems to me that something went wrong and the
simulator is executing the infinite loop or something (because even the
trivial printf in the very beginning of the benchmark was not printed
yet).
>>
>> Did someone ever met the same behaviour with v8 benchmark
or some other workload?
>> What is the best way to debug this issue?
Printing pc seems to be very ugly idea because the benchmark is huge.
>>
Is the instruction rate (50k/s) I got is correct for the performance
model?
>>
>> Many thanks,
>> Orangeade
_______________________________________________
>> gem5-users mailing
list
>> [email protected]
>>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1]
>
>
_______________________________________________
> gem5-users mailing
list
> [email protected]
>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1]
Links:
------
[1]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
