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. - 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
