For your information, the patch has been filed to the review board.
Tao
On 10/05/2012 05:48 PM, Rio Xiangyu Dong wrote:
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 <mailto: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
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
