On 11/08, Paul E. McKenney wrote: > > On Thu, Nov 08, 2012 at 04:41:36PM -0800, Paul E. McKenney wrote: > > On Thu, Nov 08, 2012 at 06:41:10PM -0500, Mikulas Patocka wrote: > > > > > > On Thu, 8 Nov 2012, Paul E. McKenney wrote: > > > > > > > On Thu, Nov 08, 2012 at 12:07:00PM -0800, Andrew Morton wrote: > > > > > On Thu, 8 Nov 2012 14:48:49 +0100 > > > > > Oleg Nesterov <o...@redhat.com> wrote: > > > > > > > > > > > > > The algorithm would work given rcu_read_lock()/rcu_read_unlock() and > > > > synchronize_rcu() in place of preempt_disable()/preempt_enable() and > > > > synchronize_sched(). The real-time guys would prefer the change > > > > to rcu_read_lock()/rcu_read_unlock() and synchronize_rcu(), now that > > > > you mention it. > > > > > > > > Oleg, Mikulas, any reason not to move to > > > > rcu_read_lock()/rcu_read_unlock() > > > > and synchronize_rcu()? > > > > > > preempt_disable/preempt_enable is faster than > > > rcu_read_lock/rcu_read_unlock for preemptive kernels.
Yes, I chose preempt_disable() because it is the fastest/simplest primitive and the critical section is really tiny. But: > > Significantly faster in this case? Can you measure the difference > > from a user-mode test? I do not think rcu_read_lock() or rcu_read_lock_sched() can actually make a measurable difference. > Actually, the fact that __this_cpu_add() will malfunction on some > architectures is preemption is not disabled seems a more compelling > reason to keep preempt_enable() than any performance improvement. ;-) Yes, but this_cpu_add() should work. > > Careful. The real-time guys might take the same every-little-bit approach > > to latency that you seem to be taking for CPU cycles. ;-) Understand... So I simply do not know. Please tell me if you think it would be better to use rcu_read_lock/synchronize_rcu or rcu_read_lock_sched, and I'll send the patch. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
