Hello All, This is a follow up to my earlier email. Earlier I had found that all cache access for the simulated benchmark execution are done through src/cpu/simple/timing.cc even when Detailed CPU is used. From what I can see in the timing.cc file, all cache accesses seem to be done through the * sendTimingReq(pkt)* function call. Can someone please confirm if my understanding is correct?
I am trying to attach the PC of requesting instruction to the packets that flow through the RUBY memory system. I am noticing that I am missing a few PCs. at the L1 cache. Thanks in advance. Akhil On Fri, Apr 26, 2013 at 4:24 PM, Akhil Arunkumar <[email protected]> wrote: > Hi, > > My system is X86. To get to my region of interest, I run under "Atomic" > mode till the starting point of my ROI and take a checkpoint (I use > --maxinsts and --checkpoint-at-end). Next I start the simulation of my ROI > by restoring from this checkpoint with cpu type "Detailed" and use > MESI_CMP_directory coherence protocol. > > I am observing that the simulation enters detailed mode as soon as I start > the command. It continues to be in detailed till the checkpoint retrieval > is complete, I think. However, after the benchmark execution begins it > switches itself to "simple" cpu. This is very strange because I did not > give any command that would make it to switch back. > > I verified this by inserting print statements at different parts of each > pipeline. Please see the console output, after inserting these print > statements, below. > > Can anybody please help me with this? How can I make sure my entire > simulation runs in Detailed mode? > > Thanks in advance. > > Akhil > > gem5 Simulator System. http://gem5.org > gem5 is copyrighted software; use the --copyright option for details. > > gem5 compiled Apr 26 2013 15:29:45 > gem5 started Apr 26 2013 15:31:18 > gem5 executing on espresso > command line: ./build/X86_MESI_CMP_directory/gem5.debug -d > m5out/X86_mcf/test/ configs/example/ruby_fs.py -n 4 --mem-size=2GB --ruby > --caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=1MB > --l1d_assoc=2 --l1i_assoc=2 --l2_assoc=16 > --kernel=/home/arunkumar/full_system_images/x86_img/binaries/x86_64-vmlinux-2.6.22.9.smp > --disk-image=/home/arunkumar/full_system_images/x86_img/disks/x86root.img > --script=/home/arunkumar/gem5/configs/boot/spec_mcf.rcS --maxinsts=1000000 > --checkpoint-dir=/home/arunkumar/gem5/m5out/X86_mcf/simpoints/ > --restore-with-cpu=detailed -r 1 > Global frequency set at 1000000000000 ticks per second > info: kernel located at: > /home/arunkumar/full_system_images/x86_img/binaries/x86_64-vmlinux-2.6.22.9.smp > 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 > Switch at curTick count:10000 > info: Entering event queue @ 29068992038500. Starting simulation... > Switched CPUS @ tick 29068992048500 > switching cpus > info: Entering event queue @ 29068992048500. Starting simulation... > O3 - RecvRetry > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > O3 - SendStore 0 > **** REAL SIMULATION **** <-------- I a guessing this marks the > beginning of the benchmark execution > info: Entering event queue @ 29072588684000. Starting simulation... > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple = handleWrite > Simple = handleWrite > Simple - sendFetch > Simple - sendFetch > Simple = handleWrite > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple - sendFetch > Simple = handleWrite > .... > .... > .... > > > > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
