Thank you for answering my question Joel. I imagined that it must be a very simple solution to my problem. Like I said: newbie.
However, now that the fast forwarding and switching works just fine, I encountered another problem. As you can see from my command line I use a custom flag (--trace-flags=myflag). This prints out the sim_seconds and sim_insts stats at certain points during my simulation. I only reset these stats in the beginning of my application (after OS boot). However, right after the cpu switch, the sim_seconds stat changes drastically: from 0.048698 s to 0.000032542 s (and the next values after this are just as little), as if it was reset. Does the switchcpu event triggers a reset of stats? Or is it something like because of the cpu switch, the way the simulated time is recorded changes? Thanks Alexandru ________________________________ From: Joel Hestness <[email protected]> To: gem5 users mailing list <[email protected]> Sent: Thu, June 23, 2011 7:19:44 AM Subject: Re: [gem5-users] About using fast forwarding Hi Alexandru, It looks like you should drop the "--standard-switch" flag. What is happening is your simulation enters timing memory mode immediately when it is started (where it says "Changing memory mode to timing"). When that happens, the simulation will handle all the latencies of the memory system and CPU instead of handling them atomically/instantly, which probably accounts for the increased simulation time that you're seeing. Hope that helps, Joel On Wed, Jun 22, 2011 at 9:01 AM, Iordan Alexandru <[email protected]> wrote: Hello > >I am new to fast forwarding and I have been struggling with a problem for some >days. I am trying to reduce the simulation time for my multiprocessor FS >simulations and in order to do that I want to fast forward to a specific >instruction count and execute in detailed mode from that point. Joel Hestness's >example from the ISCA 2011 tutorial does not apply in my case since I do not >want to switch in the beginning of my application but somewhere in the middle of >it. I used the following command line: > >./build/ALPHA_FS/m5.opt --trace-flags=myflag --trace-file=my_trace.out >--outdir=stats/ configs/example/fs.py -n 2 --script=my_script.rcs --detailed >--caches --l2cache --standard-switch -F 100967666 > >The fs.py script is the one distributed with M5 and I only modified some cache >parameters (size etc.). To my understanding, the above command should start the >simulation using AtomicSimpleCPU and after 100967666 instructions (this >instruction count includes the boot and the initialization part of my >application) should switch to detailed mode. However, the simulation takes way >to much time (longer than it takes to run without the fast forward). M5's output >is: > >M5 compiled Jun 22 2011 13:09:22 >M5 revision e46d048f7e69+ 7074+ default tip >M5 started Jun 22 2011 14:02:50 >M5 executing on ubuntu >command line:./build/ALPHA_FS/m5.opt --trace-flags=myflag >--trace-file=my_trace.out --outdir=stats/ configs/example/fs.py -n 2 >--script=my_script.rcs --detailed --caches --l2cache --standard-switch -F >100967666 >Global frequency set at 1000000000000 ticks per second >info: kernel located at: /home/vadmin/FullSystemImages/binaries/vmlinux >Listening for system connection on port 3456 >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:100967666 >info: Entering event queue @ 0. Starting simulation... >warn: 337326000: Trying to launch CPU number 1! >For more information see: http://www.m5sim.org/warn/8f7d2563 >hack: be nice to actually delete the event here >Switched CPUS @ cycle = 2338577694000 >Changing memory mode to timing >switching cpus >Switch at instruction count:0 >info: Entering event queue @ 2338577694000. Starting simulation... >Switching CPUS @ cycle = 2340348678000 >Simulation ends instruction count:0 >info: Entering event queue @ 2340348678000. Starting simulation... >switching cpus >**** REAL SIMULATION **** >info: Entering event queue @ 2340348679000. Starting simulation... >warn: allocating bonus target for snoop >For more information see: http://www.m5sim.org/warn/f15ea301 >warn: allocating bonus target for snoop >For more information see: http://www.m5sim.org/warn/f15ea301 >warn: allocating bonus target for snoop >For more information see: http://www.m5sim.org/warn/f15ea301 >warn: allocating bonus target for snoop >For more information see: http://www.m5sim.org/warn/f15ea301 >warn: allocating bonus target for snoop >For more information see: http://www.m5sim.org/warn/f15ea301 > > > >Am I doing something really stupid here? Can anyone provide me some insight into >how to use fast forwarding or at least point me towards some documentation ( I >already read http://www.m5sim.org/Sampling)? > >Thanks in advance! >Alexandru > >_______________________________________________ >gem5-users mailing list >[email protected] >http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
