On Mon, Dec 27, 2010 at 5:11 AM, nathan binkert <[email protected]> wrote:
> > I don't think we always drain on a per-System basis though... e.g., when > we > > checkpoint, don't we do a drain on the entire config? And in that case > > there are things like Ethernet links that may need to be drained but > aren't > > necessarily below any System object in the hierarchy. > Yes, but when we switch over in a two system setting, I don't believe > that we drain the non-switching. I think we're talking past each other here... I agree (and always have) that we sometimes drain system A but not system B, and that we want to keep that ability. Right here I'm just saying, in response to Ali's proposal, that there are also times when we drain the entire configuration, and in those cases, only being able to drain on a per-system basis is inadequate because there could be SimObjects that need draining outside of any system. > I'd also honestly worry that you > could have two independent drains going on if there were sampling on > systems. It seems that making all systems wait for the slowest > drainer would be a bad idea. Thinking forward to multithreaded > simulation, drain would be annoying as a global. Finally, if we're > going to eventually have to drain on functional accesses (or writes) > for ruby, that seems bad in a multisystem setting. One system doing a > syscall should not affect another system as this would really be > confusing when trying to understand performance. > Good points... I had forgotten about the drain-for-functional-accesses proposal. That's probably enough to kill the global right there. > > One option would be to have a set of SimObject classes that can serve as > the > > root of a draining subtree, and include both System and Root in that set. > > Or we could have every SimObject have that potential at the cost of an > > extra int per SimObject. > I don't have a strong opinion on this. It would certainly be nice to > cut down on the amount of data, but not critical. > > I guess I don't have a good feeling about how difficult any of this is > going to be. It seems to me that the global is a bit rough for either > multithreaded or multisystem simulations or for functional drain > requirements. > Yea, I think it's either some per-SimObject thing or wrapping the callback, I think. One danger this brings up is how do we handle potential drains that overlap in both the set of objects they want to drain and in time? E.g., what if while I'm draining system A for a mode switch, I hit some other event that wants to initiate a checkpoint so it kicks off a config-wide drain? I don't know that we need to handle this, but we should at least detect it and block one of them, if we're serious about allowing concurrent drains. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
