> I don't think reader/writer locks will be appropriate for most things. > Either lockfree data structures or replication will probably provide higher > performance in most cases. I didn't mean that this should be forever. Just a starting place.
> The list of things that need some sort of solution is: > FastAlloc > RefCount > StaticInst::decode() > EventQueue > > FastAlloc is a tricky since the pools need some protection. Replication > doesn't seem to immediately work since an object can be allocated on one > core and passe via an event to another core where it is deallocated. Adding > locks is probably more expensive than not using FastAlloc at all. Replication is fine. When you deallocate, you just stick the freed space on the thread local pool. We may want to periodically rebalance, or add some mechanism to call delete if a queue gets too long. Initially, we may just want to disable it though. I'm pretty sure that new and delete are a lot faster now than they once were. > RefCount atomic_inc/atomic_dec is probably the best bet since it could > happen on any core. Well, it's a question of which objects can have references in multiple threads simultaneously. We could also be more careful to not just blindly use the reference counting pointer unless we really are hanging onto a reference. > StaticInst::decode() Perhaps replication would be a good place to start. I > think the structure is just accessed too much to have any kind of locking. I agree that replication can work, but I'd say we start with a rwlock and then replicate once we get a running system. > EventQueue lockfree? Well event queues can be completely lock/atomic free as long as you we specially handle cross scheduling events. Periodically checking a cross thread producer/consumer queue is probably the way to go. The workings of this are closely related to how we deal with slack between queues. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
