You're going to need to add an item to that your plan to lock around or duplicate shared structures. Miles got these all to work, but in many cases they were with locks that killed performance.
Places that come to mind are: FastAlloc pools RefCounted (yet another reason to not refcount memory objects) StaticInst cache The FastAlloc pools and StaticInst cache should clearly be duplicated. RefCounted will need some work though. I think the only problematic case is the EthPacketData and perhaps the statistics at the moment. Ali On Jun 29, 2008, at 12:23 PM, nathan binkert wrote: > I'm nearly done with the first step of getting parallel M5 working. > -- Add an EventQueue pointer to every SimObject and add > schedule()/deschedule()/reschedule() functions to the Base SimObject > to use that event queue pointer. > -- Change all calls to event scheduling to use that EventQueue > pointer. > -- Remove the schedule/deschedule/reschedule functions on the Event > object. Now, you must create an event and schedule it on an event > queue. > > An example of this is something like this: > > old: > new LinkDelayEvent(this, packet, curTick + linkDelay); > > new: > Event *event = new LinkDelayEvent(this, packet); > this->schedule(event, curTick + linkDelay); > > I'd like to remove the queue pointer from the event object since there > is only one use case where you've scheduled an event and you don't > know which queue it's on if you want to de/reschedule it. It's for > repeat events like the SimLoopExitEvent. > > Here are the options: > 1) Leave the queue pointer in the object > 2) Pass the queue pointer as a parameter to the process() function > 3) Record the queue pointer in just those objects that require it > 4) Create a new flag to the event called AutoRepeat, create a virtual > function that can be called to determine the repeat interval, and add > support for repeat in the event queue > 5) Create a thread local global variable called currentEventQueue. > (I hate this idea) > > I go back and forth as to the right thing to do. I'd really like to > avoid the queue pointer in all objects so we can keep events small, > but I guess it can easily be argued that I shouldn't keep that > optimization unless I know that it will pay off, but the only way to > know if it will pay off is to just do it. I also basically hate #5 > and it's on the bottom of my list. One issue is that because of the > committed instruction queue, there can be more than one event queue in > a given thread. > > Anyone have any opinions? > > BTW: I'll write up a Parallelizing M5 wiki page in the next day or so > that enumerates all of my plans. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
