Hi Stijn, I finally got around to reading this thread on parallelizing M5. It seems that you have a reasonably good handle on the issues involved. Just so we're clear, the plan all along has been to parallelize M5. Ali mentioned the change I made about a year ago, where I gave all objects a private pointer to an event queue that it would schedule on. The idea is that each object would be bound to a particular event queue and would schedule events on that queue. Event queues would be bound to host cores. Only a few objects would schedule events on multiple queues. We are currently planning to only support shared memory machines and aren't planning to use a cluster to simulate a system.
> The thing is that a quantum of 40 cycles, is probably not going to be > sufficient for the simulations I will be running. What do you base this assertion on? You said that you'd be running hundreds of cores. This means that you're going to have 10s of simulated cores mapped onto every real core. I wouldn't jump to conclusions on this before we have any idea how things perform. > I'm guessing that simulation threads, if I were to let them run freely, would > frequently be > hundreds of cycles apart. Sure, but the real question is, how much overhead are you adding by keeping things more closely in sync. > The problem with this is that events would have to be able to say which > state objects they will be affecting (= on which eventqueues they will be > scheduling events), requiring further code changes. This is already how we are planning on doing things and the SimObject hierarchy lends itself nicely to this. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
