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 first
bug.
The first bug is related to how draining is done in the Python
interface. Normally when a configuration script (this is actually done
automatically from m5.switch_cpus() or m5.checkpoint()) requests a
drain, it calls m5.drain(). Drain notifies all components about a
pending drain and allow them to request more simulation so they can
reach a consistent state. The problem is when this additional simulation
happens. In this case a simple call to m5.simulate() is performed and
the return value is discarded. I've on several occasions had m5exit and
m5fail pseudo-ops dropped this way.
The best solution I can think of for this problem is to let m5.drain()
return a (drained, exit_event) tuple. Since there is no way to determine
if an exit event was truly fatal (I'd argue that this is a design flaw),
we can't continue to simulate at this point, instead we have to pass the
event to the simulation script. The system ends up in a sort of limbo
state if this happens, some components will have drained (e.g., CPUs may
have stopped their fetch stage), so we can't simply continue as if
nothing had happened. It's probably not safe to call resume all
components directly as this will trigger all sorts of assertion error if
a component wasn't drained.
I have an implementation of my proposed fix in my fixes[1] branch and
will (hopefully) push it for review sometime next week. We could
probably avoid the limbo state by resuming components that have drained,
but I don't think that is necessary or desirable. An unfortunate
side-effect is that we can't do reliable automatic draining in
m5.switch_cpu() and m5.checkpoint(), but simulation scripts that need
this could just drain the system themselves and disable draining by
setting the no_drain keyword argument to True.
//Andreas
[1] https://github.com/andysan/gem5/commits/fixes
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
