Re: RCU read lock vs spinlocks

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Mar 25, 2010 at 10:51:55AM +0000, David Howells wrote:
> 
> 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();

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.

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

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

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

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