Hi,Fulya The reason could be this: In the Simulation.py file, the fastforward option parameter is passed to max_insts_any_thread Since you have multiple threads running, the value you set to fastforward will stop the simulation when any of the threads reach this number, not when sim_insts reach this number.
Hui On Mon, Jul 22, 2013 at 5:55 PM, Fulya Kaplan <[email protected]> wrote: > Hi all, > I am running Parsec on X86 with the latest stable gem5 version, > gem5-stable-07352f119e48. I run blacksholes benchmark with 2 cores and 2 > threads. What i am trying to do is to fastforward until the ROI and then > switch cpus. Since I am using the precompiled Parsec binaries, I am > experimentally finding the entrance of ROI by doing a simple run first > (with AtomicSimpleCPU). The precompiled binaries are instrumented such that > the stats are automatically dumped&reset at the beginning of ROI, at the > end of ROI and at the end of the simulation. > > - The stats up to the entry of ROI looks like this: > > > ---------- Begin Simulation Statistics ---------- > sim_seconds > 0.159830 # Number of seconds simulated > sim_ticks > 159830210500 # Number of ticks simulated > final_tick > 4934687568000 # Number of ticks from beginning of > simulation (restored from checkpoints and never reset) > sim_freq > 1000000000000 # Frequency of simulated ticks > host_inst_rate > 2148597 # Simulator instruction rate (inst/s) > host_op_rate > 5054283 # Simulator op (including micro ops) rate > (op/s) > host_tick_rate > 893449596 # Simulator tick rate (ticks/s) > host_mem_usage > 1079648 # Number of bytes of host memory used > host_seconds > 178.89 # Real time elapsed on the host > sim_insts > 384364888 # Number of instructions simulated > sim_ops > 904166322 # Number of ops (including micro ops) > simulated > > - I get the sim_insts variable (384364888) from there and use it as > the number of instructions to fastforward for my second run: > > > ../build/X86/gem5.opt --outdir=../RUNS/detailed_all_bms/m5out_blackscholes > ../configs/example/fs.py > --disk-image=/home/fkaplan/Stravinsky/gem5/full_system/disks/x86root-parsec.img > --kernel=/home/fkaplan/Stravinsky/gem5/full_system/binaries/x86_64-vmlinux-2.6.28.4-smp > --script=./runscripts/blackscholes_2c_simmedium.my.rcS -n 2 > --cpu-type=detailed --caches --l2cache --num-l2caches=2 --l1d_size=32kB > --l1i_size=32kB --l1d_assoc=8 --l1i_assoc=2 --l2_size=512kB --l2_assoc=16 > --fast-forward=384364888 > > - The screen output looks like this for the 2nd run and it looks like > switchcpu occurs @ tick 5099424012500: > > > Global frequency set at 1000000000000 ticks per second > info: kernel located at: > /home/fkaplan/Stravinsky/gem5/full_system/binaries/x86_64-vmlinux-2.6.28.4-smp > 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 > Listening for com_1 connection on port 3456 > warn: Reading current count from inactive timer. > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001 > Switch at instruction count:384364888 > info: Entering event queue @ 0. Starting simulation... > warn: Don't know what interrupt to clear for console. > warn: instruction 'wbinvd' unimplemented > warn: x86 cpuid: unknown family 0x4000 > warn: instruction 'fxsave' unimplemented > warn: instruction 'wbinvd' unimplemented > hack: Assuming logical destinations are 1 << id. > warn: Tried to clear PCI interrupt 14 > warn: Unknown mouse command 0xe1. > hack: be nice to actually delete the event here > Switched CPUS @ tick 5099424012500 > switching cpus > info: Entering event queue @ 5099424012500. Starting simulation... > **** REAL SIMULATION **** > info: Entering event queue @ 5099424013000. Starting simulation... > > > - However, when i check out the stats file for this run, i see that at > the point of switchcpu, the sim_insts is a lot different than what i > specified (meaning that the switching occurs a lot later than i want/ a lot > later than the entrance of ROI): > > > ---------- Begin Simulation Statistics ---------- > sim_seconds > 0.005241 # Number of seconds simulated > sim_ticks > 5240981500 # Number of ticks simulated > final_tick > 5104664994500 # Number of ticks from beginning of > simulation (restored from checkpoints and never reset) > sim_freq > 1000000000000 # Frequency of simulated ticks > host_inst_rate > 1525098 # Simulator instruction rate (inst/s) > host_op_rate > 3162661 # Simulator op (including micro ops) rate > (op/s) > host_tick_rate > 11129462 # Simulator tick rate (ticks/s) > host_mem_usage > 1104508 # Number of bytes of host memory used > host_seconds > 470.91 # Real time elapsed on the host > sim_insts > 718184773 # Number of instructions simulated > sim_ops > 1489330630 # Number of ops (including micro ops) > simulated > > Note: I dumpreset the stats periodically and check out the values for > system.switch_cpus. Only after the above set of stats (around > tick=5104664994500, or sim_insts= 718184773), I can observe nonzero values > for switch_cpus cycles. > > Do you know what causes this discrepency? Please help. > > Best, > Fulya Kaplan > > > > > > > > > > > > > > _______________________________________________ > 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
