> 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 see. I didn't understand that. My fault. I didn't understand that the global for just the count variable and didn't really impact who could drain when. So, the thing that is dynamically allocated is the drain event, not the count, right? (I was confusing it with the CountedExitEvent which dynamically allocates the int.) I just actually looked at all of the code and agree that it is pretty darned messy, it's not even clear to me exactly how count works anymore.
> Yea, I think it's either some per-SimObject thing or wrapping the callback, > I think. Wrapping a callback isn't really that tough. I can do it for you if you like. > 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. Seems like they need to be combined in some way. A syscall needs to complete before a checkpoint, but can a drain initiate a syscall in any way? Are there any strange dependencies like this? Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
