Hi all,
I am currently struggling with a phenomenon of gem5 in X86 FS mode with
multi-core cpus. I use multithreaded splash-2 and Parsec 2.1 benchmarks
with the kernel and disk images provided on the gem5 website. I use
atomic mode to fast forward until the region of interest and the switch
to the O3 cpu.
Now the problem is that although the benchmarks should use 8 cores (8
threads), only few cores are really used, while the rest seems to remain
idle. However, this phenomenon occurs only with the O3 cpu. If I don't
switch and remain with the first mode, 8 cores are used. I tried to use
taskset, I created checkpoints to avoid forwarding/switching, I tried
fewer and more cores and threads, the problem is still there. In order
to avoid problems with the Linux scheduler, I also use taskset to avoid
using the first core, which however did not really resolve the problem.
To illustrate my problem, here is a snapshot of the resulting stats.file
of the x264 PARSEC benchmark for the region of interest.
atomic:
system.cpu00.committedInsts 929913 # Number of
instructions committed
system.cpu01.committedInsts 139072589 # Number
of instructions committed
system.cpu02.committedInsts 104962601 # Number
of instructions committed
system.cpu03.committedInsts 176170052 # Number
of instructions committed
system.cpu04.committedInsts 131944761 # Number
of instructions committed
system.cpu05.committedInsts 126332143 # Number
of instructions committed
system.cpu06.committedInsts 132647761 # Number
of instructions committed
system.cpu07.committedInsts 132356819 # Number
of instructions committed
system.cpu08.committedInsts 136295648 # Number
of instructions committed
system.cpu09.committedInsts 165557480 # Number
of instructions committed
system.cpu10.committedInsts 118983 # Number of
instructions committed
system.cpu11.committedInsts 119255 # Number of
instructions committed
with switch to O3:
system.switch_cpus_100.committedInsts_total
861885 # Number of Instructions Simulated
system.switch_cpus_101.committedInsts_total
10000000001 # Number of Instructions Simulated
system.switch_cpus_102.committedInsts_total
9999386643 # Number of Instructions Simulated
system.switch_cpus_103.committedInsts_total
850243 # Number of Instructions Simulated
system.switch_cpus_104.committedInsts_total
861640 # Number of Instructions Simulated
system.switch_cpus_105.committedInsts_total
846145 # Number of Instructions Simulated
system.switch_cpus_106.committedInsts_total
857511 # Number of Instructions Simulated
system.switch_cpus_107.committedInsts_total
846145 # Number of Instructions Simulated
system.switch_cpus_108.committedInsts_total
860387 # Number of Instructions Simulated
system.switch_cpus_109.committedInsts_total
850247 # Number of Instructions Simulated
system.switch_cpus_110.committedInsts_total
861648 # Number of Instructions Simulated
system.switch_cpus_111.committedInsts_total
862428 # Number of Instructions Simulated
I start gem5 like this:
build/X86/gem5.fast --remote-gdb-port=0 --stats-file=x264/x264.stats
--dump-config=x264/x264.config configs/example/fs.py -n 12 --caches
--l2cache --l3cache --script=configs/boot/parsec2/x264_8c_simmedium.rcS
--terminal_name=.x264 --l3tech=stt --l3stochastic=true --cpu-clock="3
GHz" -s 100 -F 500000000 --maxinsts $N
Did anybody observe such a behavior already? Has anybody an idea how I
can resolve this issue?
Best regards,
Fabian
--
Dr.-Ing. Fabian Oboril
Research Assistant (Wissenschaftl. Mitarbeiter)
Karlsruhe Institute of Technology (KIT)
Chair of Dependable Nano Computing (CDNC)
Institut für Technische Informatik (ITEC)
Haid-und-Neu-Str. 7
Building 07.21
76131 Karlsruhe, Germany
Phone: +49 721 608-44859
Fax: +49 721 608-43962
Email: fabian.oboril∂kit edu
Web: http://cdnc.itec.kit.edu/
KIT – The Research University in the Helmholtz Association
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
