On Fri, Nov 09, 2012 at 05:35:38PM +0100, Oleg Nesterov wrote: > 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.
Indeed! But this_cpu_add() just does the preempt_enable() under the covers, so not much difference from a latency viewpoint. > > > 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. I doubt if it makes a measurable difference for either throughput or latency. One could argue that rcu_read_lock() would be better for readability, but making sure that the preempt_disable() is clearly commented as starting an RCU-sched read-side critical section would be just as good. So I am OK with the current preempt_disable() approach. Thanx, Paul -- 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/