> First, let me get a clearer picture of which code changes will be > required. I'll email my ideas and after some revision I would appreciate > it if you walked me through some of the code over the phone (do you Skype?). I can do Skype at home (HP doesn't like it), but I can just call you if I'm at the office. I can also set up a conference call (with local numbers for everyone) if multiple people are interested in discussing this. (Steve and Ali would probably be good people to have on such a call.)
> As far as me being committed to making this happen. I would like to but > I can't say for sure that I will have enough time (finishing my thesis > is still my primary objective). However I'm pretty sure that > implementing the code to parallelize m5 safely and generically will be > beneficial to my research and require less time, in the long run, than > quick and dirty solutions. So unless some major issue emerges I plan to > get the job done. That's great to hear. I would personally really appreciate it if you worked with us to make this happen. You're already being very collaborative about this, which is great and I'm just encouraging you to continue to be so. It will make it much more likely for us to succeed. > I already have an idea of how m5 could safely simulate disjoint > collections of SimObjects of a configuration on different eventqueues in > parallel. The guarantee m5 would need to have, to let two collections > simulate out of sync safely, is that objects from different collections > only interact through events that can only affect the targeted object. > We would then have disjoint collections of SimObjects where the only > references an object from one collection can have to objects from > another are those of a safe type which only allow event communication. > The python initialization code could then check the SimObjects and their > references and partition the SimObjects in such collections. It could > then automatically assign eventqueues or check if the existing > assignment of eventqueues is safe. If key SimObjects in m5 are then > modified to interact through the safe type, large sections of the > simulator could safely run concurrently. Memory ports would be good > candidates for this. I think this is very realistic. I think that (at least for the short/medium term), we should assume that the system is not parallel unless we're actually running a simulation. This will make it very easy for us to deal with configuration, statistics dumping, checkpointing, object switching, and other things that aren't performance criticial. Assuming this, there are a few global objects in M5 that we will have to deal with, but initially, we can just use reader/writer locks on them. I know of at least the instruction cache (and the event queue itself of course). Ali, wasn't there a document somewhere that spelled some of this out? Perhaps we could put this on the wiki. > Such a safe, generic type could be implemented using templates so it > wouldn't just be a interface with one method "triggerEvent(Event *e)". > Thus still allowing event type checking . I need to figure out a few > more things and then I'll email some more concrete pseudocode. I'm not clear on what you're getting at here by using types in C++. The way things currently work right now is that everything that want's to schedule an event needs to schedule it through an event manager (all SimObjects are EventManagers). An event manager is bound to a single event queue and has an internal pointer to that event queue. It's simply a matter of assigning event queues to event managers in the python config. Thus the objects that use a given event manager shouldn't even know how to access the other event queues (unless you give an object a pointer to multiple event managers.) Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
