Hi Joel,
We've been working on fixing some (non-ruby) issues as well. In the process we've also written up some documentation in doxygen, but it hasn't been comittted yet. See http://reviews.m5sim.org/r/1353/ The number that is returned from drain can be greater than one, it just means that the drainEvent->process() function will be called that many times by that object. This is useful when one SimObject has multiple sub-objects that it is responsible for, and wants those sub-objects to handle their draining individually. The drain process is repeated until all objects return 0. This is to account for one object transfering responsiblity for an outstanding request to another object. Thanks, Ali On 31.08.2012 15:58, Joel Hestness wrote: > Hi guys, > 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. > > The biggest challenge I've run into is in the RubyPort drain function, > which uses the drain functionality of the new QueuedMasterPort and > QueuedSlavePort (changeset 8914:8c3bd7bea667) during simulation after a > system-wide drain call (i.e. when called from drain() in simulate.py). > > To sort through this, I need to confirm the desired semantics of the > drain function to determine whether fixes should be made in RubyPort or the > PacketQueue. From what I observe in a handful of different SimObjects, the > drain function should: > 1) only be called during a system-wide drain process > 2) return 0 if the component is drained, and return 1 if the component > has work to do before it can be considered "drained" > > 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). > > 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. > > Please let me know if this sounds correct. > Thanks, > Joel _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
