See inline.
Currently, there are a handful of bugs that are interfering with
the drain, checkpoint and restore functionality when running sims with
Ruby. I've documented observable bugs in this
GoogleDoc<
https://docs.google.com/spreadsheet/ccc?key=0AvwlHlT78qDYdFU1clZlemYyelQxTEZyeXNBck9hNkE#gid=1>,
and
I'm currently working my way through trying to fix
things.
*This is great. I have been working on this and have fixed a few
problems, but a few more remain. I'd be happy to help out with this to
avoid duplicating work after next*
* week.*
1) only be called during a system-wide drain process
*I would say this is correct, although I can imagine cases where
you may want to drain individual components, e.g., CPU only. But, for the
switchout functionality I'd say*
* this is strictly true.*
2) return 0 if the component is drained, and return 1 if the
component has work to do before it can be considered "drained"
*It needs to return 0 if it is completely drained, but, it needs
to return the number of objects it's responsible for draining. This is the *
*number of times its drainEvent*
* should call process(). E.g., see the ARM table walker.*
*
*
Further, in the case where some components need to be drained,
the drain() function in simulate.py will call simulate(), which will
run simulation until each of the components that
returned 1 from their drain functions have cleared the work that
needed to be drained (they signal their completion by calling process on
the drain event).
*Yes.*
*
*
If the above are the desired semantics, then I believe that the
RubyPort should NOT be calling drain() on its ports while in the simulate()
phase of execution (which it currently does).
If the RubyPort does call drain during the simulate phase, then its
ports that have received new work since the system-wide drain call will no
longer be considered "drained", though
they weren't counted toward the currently executing
CountedDrainEvent. This can result in the CountedDrainEvent being processed
too many times.
* Even if all objects call process() on the drain event and
simulate() is exited **inside of drain(), the system may not be drained.
Other objects who needed to drain*
* may, while they are draining, cause other objects to no longer be
drained. So, you need to use **doDrain() when draining. If you exit
simulate() because all objs signaled*
* drained, **you need to call drain() on all objects again to
ensure that all objects are still drained. Given that, I think you may be
correct. I think what should happen is, if*
* the ports are "undrained" this should be discovered when you call
drain() again and not inside of simulate() when the drainEvent is set, as
it currently is. Looking at the*
* RubyPort's drain() code it looks like whoever wrote it, wrote it
to continually drain() its ports on its own, when it really should let the
ports be undrained and this will be*
* caught by calling drain() again. I think they were using drain()
when testing and wanted to ensure that the RubyPorts drained in one shot.*
Thanks,
Tony
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
