Re: [this_cpu_xx V2 10/19] this_cpu: X86 optimized this_cpu operations

[Tejun Heo <tj@kernel.org>]

Christoph Lameter wrote:
> On Thu, 18 Jun 2009, Tejun Heo wrote:
> 
>> Ah... okay, so it's supposed to take a lvalue.  I think it would be
>> better to make it take pointer.  lvalue parameter is just weird when
>> dynamic percpu variables are involved.  The old percpu accessors
>> taking lvalue has more to do with the way percpu variables were
>> defined in the beginning than anything else and are inconsistent with
>> other similar accessors in the kernel.  As the new accessors are gonna
>> replace the old ones eventually and maybe leave only the most often
>> used ones as wrapper around pointer based ones, I think it would be
>> better to make the transition while introducing new accessors.
> 
> The main purpose of these operations is to increment counters. Passing a
> pointer would mean adding the & operator in all locations. Is there any
> benefit through the use of the & operator?
> 
> lvalues of structs in the form of my_struct->field is a natural form of
> referring to scalars.
> 
> The operation occurs on the object not on the pointer.
> 
> The special feature is that the address of the object is taken and its
> address is relocated so that the current processors instance of the object
> is used.

Functionally, there's no practical difference but it's just weird to
use scalar as input/output parameter.  All the atomic and bitops
operations are taking pointers.  In fact, there are only very few
which take lvalue input and modify it, so I think it would be much
better to take pointers like normal C functions and macros for the
sake of consistency.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>