Re: [PATCH RFC tip/core/rcu 11/11] rcu: move TREE_RCU from softirq to kthread

[Frederic Weisbecker <fweisbec@gmail.com>]

On Wed, Feb 23, 2011 at 11:41:42AM -0500, Steven Rostedt wrote:
> On Wed, 2011-02-23 at 17:16 +0100, Frederic Weisbecker wrote:
> > I see you make extensive use of per_cpu() accessors even for
> > local variables.
> > 
> > I tend to think it's better to use __get_cpu_var() for local
> > accesses and keep per_cpu() for remote accesses.
> > 
> > There are several reasons for that:
> > 
> > * __get_cpu_var() checks we are in a non-preemptible section,
> > per_cpu() doesn't. That may sound of a limited interest for code like the
> > above, but by the time code can move, and then we might lose track of some
> > things, etc...
> 
> Ah, but so does smp_processor_id() ;-)

Ah, right :)
 
> > 
> > * local accesses can be optimized by architectures. per_cpu() implies
> > finding the local cpu number, and dereference an array of cpu offsets with
> > that number to find the local cpu offset.
> > __get_cpu_var() does a direct access to __my_cpu_offset which is a nice
> > shortcut if the arch implements it.
> 
> True, but we could also argue that the multiple checks for being preempt
> can also be an issue.

It's only in debugging code, so it's not really an issue.
 
> > 
> > * It makes code easier to review: we know that __get_cpu_var() is
> > for local accesses and per_cpu() for remote.
> 
> This I'll agree with you.
> 
> In the past, I've thought about which one is better (per_cpu() vs
> __get_cpu_var()).
> 
> But, that last point is a good one. Just knowing that this is for the
> local CPU helps with the amount of info your mind needs to process when
> looking at this code. And the mind needs all the help it can get when
> reviewing this code ;-)

Yeah :-)

And that becomes even better when you have the opportunity to
use get_cpu_var(). So that tells that your are doing a local access
and the reason why you disable/enable preemption.