On 9/26/07, Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 26, 2007 at 05:07:33PM -0400, Steven Rostedt wrote: > > > > -- > > On Wed, 26 Sep 2007, Peter Zijlstra wrote: > > > > > > On Wed, 2007-09-26 at 12:55 -0700, Paul E. McKenney wrote: > > > > > > > Well, we could make spin_lock_irqsave() invoke rcu_read_lock() and > > > > spin_lock_irqrestore() invoke rcu_read_unlock(), with similar adjustments > > > > to the other primitives in this group. Then RCU priority boosting would > > > > kick in if configured. > > > > > > Might be me, but 'hiding' the RCU scope like that makes my skin crawl. > > > What is wrong with using rcu_read_lock() explicitly where you depend on > > > it? It even makes the code cleaner in that it documents the usage. > > > > > > These blanket locks like lock_kernel(), preempt_disable(), > > > local_irq_disable() etc. are very hard to get rid of because they don't > > > document what is protected. > > > > > > Please lets not add to this mess and keep all this explicit. > > > > > > Yes, -rt changes the preemption model, and that has concequences. But > > > IMHO the resulting code is cleaner in most cases. > > > > > > I'd go as far as to depricate synchronize_sched() and replace all its > > > users with proper RCU. > > > > > > The more I think of it, the more I dislike this synchronize_all_irqs() > > > and the 'magic' property of irq handlers. > > > > Thinking a little more about this, I fully agree with Peter. > > Again, it is not me that you need to convince. ;-) > > > What code needs to know that all spin_locks have released, or you want to > > know all irq handlers are done? > > > > Seems that this is a broad data to ask for and will be a bitch to clean up > > when we find out that this is not scalable. This all sounds like > > reinventing the BKL. > > It would scale just fine, and inherently does not need priority boosting > (since preempted/blocked things cannot hold up sychronize_sched()). > That said, I do agree with you that having things explicit is a good > thing. > > > If you simply want a RCU type of scheme, then simply use RCU. I second > > deprecating "synchronize_sched". Everything that does RCU type locking > > (that is waiting for some kind of grace period to finish) should simply > > use RCU and not a "wait for all processes to voluntarily schedule" or > > "wait for all interrupt handlers to finish". > > Here are the uses in 2.6.23-rc6. There are several that might not > be so easy to replace with RCU. > I will look into converting into "proper RCU" but I'd like you to consider one more thing - proper RCU disables preemption, correct? So it seems that converting code to "proper RCU" to some degree negates the benefits of sleeping spinlocks introduced in -rt. If there was a way to create synchronize_irq_spinlocks() that is separate from RCU and could be preempted that would give the best of the 2 worlds. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
