Hi all,
I am running Parsec with multicore using X86 FS with Ruby memory model and the
latest stable gem5 version. I successfully took a checkpoint using the “timing
simple cpu” and then restored from the checkpoint using
“—restore_with_cpu=detailed” option.
My first question is what is the difference between using “restore_with_cpu”
option and “cpu_type” option in terms of functionality? (When I tried to
restore using “cpu_type”, I got an error.)
My end goal is to restore from the checkpoint and run the rest of the benchmark
using the detailed cpu. In order to check if detailed cpu is actually used
after switching, I put a printf statement in /src/cpu/o3/cpu.cc within the
instDone function as shown below and rebuilt gem5:
FullO3CPU<Impl>::instDone(ThreadID tid, DynInstPtr &inst)
{
// Keep an instruction count.
if (!inst->isMicroop() || inst->isLastMicroop()) {
thread[tid]->numInst++;
thread[tid]->numInsts++;
committedInsts[tid]++;
}
thread[tid]->numOp++;
thread[tid]->numOps++;
committedOps[tid]++;
system->totalNumInsts++;
/*Fulya ’s printf statement*/
std::cout<<"totalNumInsts="<<system->totalNumInsts<<endl;
/*End of Fulya’s printf statement*/
// Check for instruction-count-based events.
comInstEventQueue[tid]->serviceEvents(thread[tid]->numInst);
system->instEventQueue.serviceEvents(system->totalNumInsts);
}
It prints the statement when a new instruction is committed until the the cores
are switched (about 130 instructions). However, after the point where it prints
out **** REAL SIMULATION ****, it stops printing the instruction count. I am
suspecting that it actually starts the simulation with O3 cpu, switches right
after to timing cpu and run the simulation with timing cpu. This does not make
sense, but could it be the case?
Best,
Fulya
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
