> OK, I had completely forgotten about your binning thing... just went > back and looked at the code to refresh my memory. I thought you were > trying to add something like binning in with this extension you're > proposing, but it's already there. So what you're saying is that > there'd be a second overloaded form of schedule that just says "here's > another guy who I know is in the same bin"? That doesn't sound so > bad. Yeah, that's all. Though I would add a check to verify that it's in the same bin and then do the normal schedule function if it is not.
> I am generally leery of the idea of having multiple events at the same > tick & priority without any way to order them deterministically... > while you're right that you don't want people to depend on a certain > ordering, you're also guaranteeing that, once we go parallel, people > who accidentally do have dependencies will end up with very painful > non-repeatable bugs. It's not an easy problem to solve, though. For > example, if you knew all the events at a given priority were network > messages, you could sort them based on destination node ID or > something like that. That might be a feature we want to enable for > debugging. Yeah, we don't have a system for this yet. But what I'm proposing won't make that worse. In the debug mode, we can just ignore the hint and schedule normally. What will happen with this change is that events will no longer be LIFO, but again, that shouldn't really matter. (And if it does, those things will really break badly in parallel mode) Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
