Hi Yi Shen, I haven't looked deeply into the problem you're describing, but from a quick glance I have a couple of suggestions: 1) Periodic stat dumps are not meant to be used every cycle. They dump stats for *every object* and generate files that are 100s of KB. This won't scale beyond a few cycles before you run out of disk space :). Instead, think you want to be using debug flags or the probe interface. If you're looking for something like trace generation, the probe interface is there for you to put in "probes" into the microarchitecture or the memory system and dump traces to a file. If you just want to *see* what's going on, often debug flags are your best bet (e.g., Exec shows what is committed every cycle). 2) You may want to think about writing your own runscript for gem5 instead of using fs.py. Then, rather than using the periodic stat dump option you can configure the simulator to do exactly what you want. For instance, you can call "simulate()" with exactly 270ps and then call dump or dump and reset on the stats for every single 270ps time frame. 3) Finally, you might want to start by running at a more evenly divisible clock period (e.g., 1GHz) to make sure things work as you expect before trying to go to a clock period that is not evenly divisible into picoseconds. You could also set the global tick rate to something less than 1ps if that's helpful.
Cheers, Jason On Wed, Dec 12, 2018 at 5:23 PM Yi Shen <[email protected]> wrote: > Hi, > > > > We are trying to get per-CPU-cycle data from gem5 and we are using > “periodicStatDump(n)” to get the data, where n is the rounded inverse of > CPU frequency in picoseconds. For our 3.7 GHz X86 CPU, n would be 270 (in > picosecond) > > > > When invoking peridoicStatDump(n) with a small n (we are using n = 270), > the stat from Gem5 becomes apparently unreliable. Since I can’t upload > picture here, here is a google doc link instead: > > > https://docs.google.com/document/d/1dBIwWeaC-QXqGX8ozcLaKFkMxnFGhYeJq6FVgf6g8l4/edit?usp=sharing > > > > Here is a brief description of the figures in the google doc: > > 1. Only core0’s numCycle (number of CPU cycle) is “around” 1 and > the other core1 shows mostly 0 CPU cycles. I believe it implies that core1 > is not working. > > 2. For the working core0, its numCycle shoots up to hundreds > occasionally (absolutely not expected), where it should be constantly 1. > > 3. If we calculate the average CPU cycles of core0 for all the > dumps, it is close to 1. > > 4. We also did some experiments with n = 270 * 10, 270 * 100 and > 270 * 4400000, all had kind of similar results. > > 5. We tried to use m5ops in rcS file. By setting “dumpresetstats 0 > 1”, it gives CPU cycles in millions. > > > > Please note, I am confident to claim that strange behaviors of both cores > persist regardless of the usage of checkpoint, the usage of ruby, changing > n=270 to 271 or the completion of booting process. None of those factors > matter. > > > > To further illustrate the problem and reproduce the scenario, here are > more details. > > The Gem5 was compiled using X86_MOESI_hammer which is renamed from > NULL_MOESI_hammer. > > All configurations used are from default fs.py and some minimal changes > has been made to invoke periodicStatDump. ( 1 line for import and 1 line > for call). Here are the configs: > > > > $x865/build/X86_MOESI_hammer/gem5.opt \ > > --outdir=$dump/$1 \ > > $fs/fs_pdump.py \ > > --script=$rcs/fluidanimate_2c_simsmall.rcS \ > > --kernel=$tool/FS_util/binaries/x86_64-vmlinux-2.6.22.9.smp \ > > --disk-image=$tool/FS_util/disks/x86root-parsec.img \ > > --cpu-type=DerivO3CPU \ > > --sys-clock='3.7GHz' \ > > --cpu-clock='3.7GHz' \ > > --sys-voltage='0.8V' \ > > --l1i_size=32kB \ > > --l1d_size=32kB \ > > --l2_assoc=8 \ > > --caches \ > > --l2cache \ > > --l2_size=2MB \ > > --num-cpus=2 \ > > --mem-size='2GB' \ > > --dumpcycles=1 \ > > --ruby \ > > > > The command in $rcs/fluidanimate_2c_simsmall.rcS is here: > > > > #!/bin/sh > > # File to run the fluidanimate benchmark > > cd /parsec/install/bin > > echo "start" > > ./fluidanimate 2 5 /parsec/install/inputs/fluidanimate/in_35K.fluid > /parsec/install/inputs/fluidanimate/out.fluid > > echo "Done :D" > > /sbin/m5 exit > > > > Sincerely request help, > > Yi Shen > > > _______________________________________________ > 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
