When we specify some option like switch from cpu type x to cpu type y
after N instructions, we insert an exit event in the instruction event
queue of each cpu that is simulated. Assume we are simulating two cpus and
that both them hit this exit event on the same tick. Then, the first such
event would result in the cpus being switched. After the switch, the
system will resume and the next exit event is executed. The code in the
file configs/common/Simulation.py will end the simulation in such a
scenario.
I agree we should revert the patch. We should have only one such event,
may be we should insert this event in the event queue of one of the cpus
only.
--
Nilay
On Sat, 1 Jun 2013, Steve Reinhardt wrote:
I agree that this patch seems wrong. I don't fully understand the scenario
that this patch was intended to fix, and I wonder if it's not a problem
with the user specification and not with the code itself (i.e., the problem
description in the patch makes it sound like perhaps -I was being used
incorrectly).
Steve
On Sat, Jun 1, 2013 at 6:48 AM, Andreas Sandberg <[email protected]>wrote:
Hi Everyone,
I started to run some simulations where I need to switch CPUs and I've
recently just run into a couple of bugs related to draining. Both are
pretty serious as they can potentially lead to very surprising when
switching CPUs in the middle of a simulation where m5ops are used. I'd like
some feedback on the proposed solutions before I post them for a formal
review. I've split the description of the bugs into two separate emails to
keep the email threads cleaner. This email discusses the second bug.
The second problem is due to the code committed as a result of RB1462[1]
(HG changeset 34e3295b0e39). The changeset introduces a check in simulate()
that causes the simulation loop to only deliver the first exit event at
every tick. I really fail to see how it can be correct for the event loop
to only be allowed to execute one exit event per tick. It supposedly fixes
"early termination in multi-core simulation under SE mode", but shouldn't
this have been fixed by adding support for handling exit events in the
simulation script instead?
In my simulation runs I sometimes end up having an exit due to a finished
drain scheduled at the same tick as an exit due to an m5fail pseudo op. I
obviously want to know about the the second event as this tells me that my
simulation failed and shouldn't go on wasting cycles. As far as I can tell,
this changeset is obviously incorrect and should be reverted. Does anyone
else have any opinions about this?
//Andreas
[1] http://reviews.gem5.org/r/**1462/diff/<http://reviews.gem5.org/r/1462/diff/>
______________________________**_________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
