On Tue, Mar 22, 2005 at 02:04:46AM -0800, Bill Huey wrote: > RCU isn't write deterministic like typical RT apps are[, so] we can... (below > :-)) ... > Just came up with an idea after I thought about how much of a bitch it > would be to get a fast RCU multipule reader semantic (our current shared- > exclusive lock inserts owners into a sorted priority list per-thread which > makes it very expensive for a simple RCU case[,] since they are typically very > small batches of items being altered). Basically the RCU algorithm has *no* > notion of writer priority and to propagate a PI operation down all reader[s] > is meaningless, so why not revert back to the original rwlock-semaphore to > get the multipule reader semantics ?
The original lock, for those that don't know, doesn't strictly track read owners so reentrancy is cheap. > A notion of priority across a quiescience operation is crazy anyways[-,-] so > it would be safe just to use to the old rwlock-semaphore "in place" without > any changes or priorty handling add[i]tions. The RCU algorithm is only > concerned > with what is basically a coarse data guard and it isn't time or priority > critical. A little jitter in a quiescence operation isn't going to hurt things right ?. > What do you folks think ? That would make Paul's stuff respect multipule > readers which reduces contention and gets around the problem of possibly > overloading the current rt lock implementation that we've been bitching > about. The current RCU development track seem wrong in the first place and > this seem like it could be a better and more complete solution to the problem. Got to get rid of those typos :) bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/