RCU read lock vs spinlocks

If a function needs both a spinlock and the RCU read lock, is there a best order in which they should be taken? For instance, is:

	spin_lock(&my_lock);
	rcu_read_lock();
	...
	rcu_read_unlock();
	spin_unlock(&my_lock);

better than:

	rcu_read_lock();
	spin_lock(&my_lock);
	...
	spin_unlock(&my_lock);
	rcu_read_unlock();

And does it make any different if spin_lock_irq*() is used?

In fact, should spin_lock_irq*() imply rcu_read_lock()? Given that the current task can't be preempted if there can be no interrupt to do the preempting?

David

The short answer is that it usually doesn't matter.

If you want the long answer... In a !CONFIG_PREEMPT kernel, it won't matter at all because rcu_read_lock() and rcu_read_unlock() generate no code. In a CONFIG_PREEMPT kernel, if you had a highly contended lock, then the second approach would be marginally better, but it would be even better to reduce that lock's contention, which would make it not matter. On the other hand, if you were running in a -rt kernel, and again had a highly contended lock, then the first approach would avoid blocking in an RCU read-side critical section, which is a bit more efficient. But again, it would be even better to reduce the contention on the lock.

Use of spin_lock_irq*() removes the -rt preference.

No, but spin_lock_irq*() -does- imply rcu_read_lock_sched() and rcu_read_lock_bh(). As an accident of the implementation, but -only- in non-rt kernels, spin_lock_irq*() happens to currently imply rcu_read_lock(), but please, please, please do not write code relying on this. It will break. :-(

Thanx, Paul