On Fri, Apr 16, 2010 at 09:37:02PM +0200, Peter Zijlstra wrote: > On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote: > > o mutex_lock(): Critical sections need not guarantee > > forward progress, as general blocking is permitted. > > > Right, I would argue that they should guarantee fwd progress, but due to > being able to schedule while holding them, its harder to enforce. > > Anything that is waiting for uncertainty should do so without any locks > held and simply re-acquire them once such an event does occur. Agreed. But holding a small-scope mutex for (say) 60 seconds would not be a problem (at 120 seconds, you might start seeing softlockup messages). In contrast, holding off an RCU grace period for 60 seconds might well OOM the machine, especially a small embedded system with limited memory. > > So the easy response is "just use SRCU." Of course, SRCU has some > > disadvantages at the moment: > > > > o The return value from srcu_read_lock() must be passed to > > srcu_read_unlock(). I believe that I can fix this. > > > > o There is no call_srcu(). I believe that I can fix this. > > > > o SRCU uses a flat per-CPU counter scheme that is not particularly > > scalable. I believe that I can fix this. > > > > o SRCU's current implementation makes it almost impossible to > > implement priority boosting. I believe that I can fix this. > > > > o SRCU requires explicit initialization of the underlying > > srcu_struct. Unfortunately, I don't see a reasonable way > > around this. Not yet, anyway. > > > > So, is there anything else that you don't like about SRCU? > > No, I quite like SRCU when implemented as preemptible tree RCU, and I > don't at all mind that last point, all dynamic things need some sort of > init. All locks certainly have. Very good!!! I should clarify, though -- by "explicit initialization", I mean that there needs to be a run-time call to init_srcu_struct(). Unless there is some clever way to initialize an array of pointers to per-CPU structures at compile time. And, conversely, a way to initialize pointers in a per-CPU structure to point to possibly-different rcu_node structures. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html