Hi all,
I have been running Parsec benchmarks with x86 FS mode. I am running 4 cpus, 4
threads and using simlarge input set. My gem5 version is the latest stable
version (gem5-stable-aaf017eaad7d). I am using the x86_64-vmlinux-2.6.28.4-smp
kernel and the parsec image provided on the UT Austin website. My problem is
that some cpus seem to hang there doing nothing resulting in unrealistically
low number of committed instructions. Below are some of the statistics for the
ROI portion of canneal:
system.cpu0.committedInsts 831079737 #
Number of instructions committed
system.cpu1.committedInsts 512473 #
Number of instructions committed
system.cpu2.committedInsts 396574208 #
Number of instructions committed
system.cpu3.committedInsts 409403428 #
Number of instructions committed
system.cpu0.numCycles 1671471523 #
number of cpu cycles simulated
system.cpu1.numCycles 1618509331 #
number of cpu cycles simulated
system.cpu2.numCycles 1645375971 #
number of cpu cycles simulated
system.cpu3.numCycles 1646168550 #
number of cpu cycles simulated
In this example, I used the atomic cpu and simply ran the benchmarks from the
beginning till the end, and reported the 2nd set of stats, which correspond to
ROI. It looks like cpu0, cpu2, and cpu3 executed ~0.83, 0.4, and 0.41 billion
instructions, respectively. Cpu1, on the other hand, executed only 0.0005
billion instructions, which is negligible compared to the others. I am thinking
this may be a linux scheduling issue. Does anyone have a solution to this
problem? I had this problem a while ago
(http://www.mail-archive.com/gem5-users%40gem5.org/msg08466.html) and still
could not figure out a solution.
Best,
Fulya
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
