Re: [PATCH 13/16] percpu: remove per_cpu__ prefix.

[Tejun Heo <tj@kernel.org>]

Hello, Christoph, Tony.

Christoph Lameter wrote:
> On Wed, 14 Oct 2009, Luck, Tony wrote:
> 
>>> we would still have to use per cpu operations to get to the contents of
>>> these variables.
>> That's good.
>>
>>> Hope that addresses your concerns.
>> But then I don't understand the original patch that was going to do:
>>
>>> -#define __ia64_per_cpu_var(var)	per_cpu__##var
>>> +#define __ia64_per_cpu_var(var)	var
>> Presumably all actual use of __ia64_per_cpu_var is being replaced
>> by some other "per cpu operations"?

Yeah, I wasn't so sure what to do about these, so just left them as
no-op for the moment.

> Hmmm... Right. IA64 is a special case because the access of the per cpu
> variable at a specific address causes per cpu TLBs to do the relocation.
> 
> Other platforms have to add a per cpu specific offset to a variable to get
> the right per cpu variable.
> 
> As a result IA64 strictly does not need this_cpu_read() and
> this_cpu_write(). However, not using the operations is going to cause
> the sparse annotation by Tejun to trigger errors. this_cpu_read() is
> likely a noop for IA64 that just changes the annotations so that sparse
> warnings do not trigger. Tejun?

__ia64_per_cpu_var() is slightly different from this_cpu_read() in
that the former only works for percpu variables which fall on the
first percpu page - ie. static percpu vars in the kernel image.  So,
__ia64_per_cpu_var() is a bit more efficient than this_cpu_read() as
it doesn't have to compute the address.

So, what we can do is to leave the macro alone for now and then add
sparse annotation to it later in the patch as it's basically another
specialized accessor.  How does that sound?

Thanks.

-- 
tejun