I think it's a very good finding. I also had the same issue (instant exit
after fast-forward when running multiple processes in SE) and I had a local
fix using the same idea (filter exit events that are labeled in one tick).
Tao, maybe you want to contact gem5-dev to add this patch, though I think
it's only necessary to use one global variable
Tick lastExitTick = 0;
.
if (exit_event != NULL) {
if (curTick() == lastExitTick)
continue;
else
lastExitTick = curTick();
// hit some kind of exit event; return to Python
// event must be subclass of SimLoopExitEvent...
.
From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On
Behalf Of Tao Zhang
Sent: Thursday, October 04, 2012 7:13 PM
To: gem5-users@gem5.org
Subject: Re: [gem5-users] problem in running multiple SAME sepc2006
benchmarks under SE mode
Finally, I fixed the problem. This is a gem5's bug when using both "-I" and
"-F" in a multi-core simulation under SE mode. Simply speaking, the problem
is caused by 'stale' exit events scheduled by Atomic CPUs, which gem5 fails
to delete before the cpu switching.
For example, if 4 cores are employed in the simulation and each core (no
matter Atomic CPU or O3 CPU) has 1 thread (numThreads = 1). Then, each core
will schedule a SimLoopExitEvent in its own comInstEventQueue (line 146-152,
src/cpu/base.cc). Once the event is detected, it's processed and an exit
event is scheduled in mainEventQueue (line 57-60, src/sim/sim_events.cc).
Since these four Atomic CPUs run the same benchmark, they hit the
instruction number specified by "-F" in the same cycle. As a result, 4
SimLoopExitEvents are scheduled in mainEventQueue.
However, the mainEventQueue can only handle one exit event at one time (line
71, src/sim/simulate.cc). The first exit event can be correctly served and
leave the rest 3 events in the mainEventQueue. The first exit event triggers
the cpu switching and the system resumes without descheduling the other 3
exit events in the mainEventQueue (line 456-458,
configs/common/Simulation.py). As a consequence, the system immediately
exits again and the whole simulation is terminated. (changeset 9217 has no
"m5.doDrain()" for the cpu switching. Even the newest changeset adds this
function, it still doesn't work).
This can explain why there is no problem in single-core simulation: only one
exit event is scheduled by Atomic CPU. This MAY also indicate that
multi-core with different benchmarks can work well, since only one local
exit event is scheduled in the mainEventQueue. ("MAY" means this should be
confirmed by gem5 maintainer).
Naively, I fixed the bug by using two global variables "exitTick" and
"exitTimesWithinOneCycle". The following code is added to
src/sim/simulate.cc.
while (1)
{
...
if (exit_event != NULL)
{
if( exitTimesWithinOneCycle == 0 )
{
exitTick = curTick();
exitTimesWithinOneCycle++;
std::cout << "This is the " << exitTimesWithinOneCycle << "
exit events!" << std::endl;
}
else
if( exitTick == curTick() )
{
exitTimesWithinOneCycle++;
std::cout << "This is the " << exitTimesWithinOneCycle
<< " exit events!" << std::endl;
continue;
}
...
}
}
On 10/04/2012 12:43 PM, Nilay Vaish wrote:
There are specific comments inline. Overall, I think you need to have a
better understanding of the options that you are trying to work with.
On Thu, 4 Oct 2012, Tao Zhang wrote:
Hi Nilay,
Maybe I didn't make it clear. What I want is to run Multi-programmed
simulation rather than multi-threaded simulation. In other words, I want 4
cores to run 4 benchmarks (though they are all same) and each core has only
1 thread. As a result, I set "np = 4 and numThreads = 1" in my configuration
script. I also produced 4 identical LiveProcess() and assigned them to each
core. However, the simulation immediately terminated after the cpu switching
from atomic to detailed, with message "a thread reached the max instruction
count". I go through the Simulation.py, src/cpu/base.cc,
src/cpu/O3/commit_impl.cc but didn't find the clue that I have wrongly set
the -F and -I with the same number (100000000).
Can you clearly state how is this different from what you expect?
If the instruction count is based on the thread and no change during the cpu
switching, why I can use -F and -I together for single-core simulation? The
Why not? You need to better understand the meaning of those two options.
final results show that the atomic cpu run the first 100000000 instructions
and then the detailed cpu run the second half instruction. The total
"sim_insts" in the final stats is 200000001. Also, I did a simple test to
What were the option values that you supplied?
change the -F and -I number as "-F 1000 -I 6000", which is supposed to work
well. Unfortunately, I got the same result...
What's the same result that you are referring to?
It should be easy to fix as soon as I can find the codes for the cpu switch.
Do you mind tell me where it is so that I can work it out? Also, I have
It is not clear what is incorrect, hence fixing some thing is not out of
question right now.
another question: Even though the benchmarks are same, I assume the physical
address range to accommodate each benchmark is still different since gem5
generates 4 process stacks with different address mapping. Is it correct?
I think this is correct.
--
Nilay
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
