Hi, I am currently using gem5 with O3 X86 cpu also. I tried simulating multicore systems (16core+) using PARSEC also. The stats file does report like what you observed, several core executed significantly amount of instructions than the rest. But I am not sure if this phenomena is equal to "the rest of cores are idle".
I am using ruby protocol package, I do found a lot of sharing among private data caches. Moreover, PARSEC benchmark suite is claimed "versatile", and it might not have all the benchmarks contain large parallel instructions. Raytrace is an benchmark simulating optical recursion which belongs to graphic app domain, which means it could be heavily paralleled. And that might lead to what you get in stats. You can refer to this paper: http://parsec.cs.princeton.edu/publications/bienia08comparison.pdf But again, the aspect that same benchmark executed on inorder/o3 showing such different behaviors are worth to be discussed. But I am sure that the every core indeed does something when running PARSEC. Someone more knowledgeable can correct me if I am wrong. Thanks, Wei ----- Original Message ----- From: "Adi Fuchs" <[email protected]> To: "gem5 users mailing list" <[email protected]> Sent: Friday, December 11, 2015 8:25:18 AM Subject: Re: [gem5-users] Parsec in X86 FS mode uses not all cores in O3 Hi Fabian, I posted a mail about that exact same issue about a week ago. From what I have seen online, it might be an issue with the way gem5 implements X86 interrupts. The same thing happens for the timing CPU as well, and I have seen it in all of PARSEC’s benchmarks, except for raytrace. I have not seen any fix for that, though. After struggling for a few weeks, I ended up giving up and using Alpha instead, where it works better, I don’t know if that works for you. I would really like to see this fixed as well. Adi From: gem5-users [mailto:[email protected]] On Behalf Of Fabian Oboril Sent: Friday, December 11, 2015 7:10 AM To: [email protected] Subject: [gem5-users] Parsec in X86 FS mode uses not all cores in O3 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 _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
