On 4/13/2023 6:24 AM, Farbin Fayza via gem5-users wrote:
Hi Heng,
Thanks for your reply. Do you mean something like this? I changed atomic.cc
like this:
void AtomicSimpleCPU::drainResume()
{
assert(!tickEvent.scheduled());
if (switchedOut())
return;
DPRINTF(SimpleCPU, "Resume\n");
verifyMemoryMode();
assert(!threadContexts.empty());
_status = BaseSimpleCPU::Idle;
*threadInfo[0]->thread->lastSuspend = curTick();*
for (ThreadID tid = 0; tid < numThreads; tid++) {
if (threadInfo[tid]->thread->status() == ThreadContext::Active) {
threadInfo[tid]->execContextStats.notIdleFraction = 1;
activeThreads.push_back(tid);
_status = BaseSimpleCPU::Running;
// Tick if any threads active
if (!tickEvent.scheduled()) {
schedule(tickEvent, nextCycle());
}
} else {
threadInfo[tid]->execContextStats.notIdleFraction = 0;
}
}
// Reschedule any power gating event (if any)
schedulePowerGatingEvent();
}
After this change, I rebuilt gem5 and ran a simulation on simple.py. But still, the number of cycles
is very higher than the number of instructions.
Some things I can imagine happening ...
- Maybe numCycles is actually number of ticks? A tick is the smallest unit of time in the system,
usually picoseconds - though that would seem to imply a really high execution rate of nearly 10
insts per nanoseond
- Maybe the cpu is idle a lot
It should not be too hard to find where those statistics are defined, output,
and manipulated
in the source code, by using grep.
HTH - Eliot Moss
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
