[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130403212450.GD3411@htj.dyndns.org>
Date: Wed, 3 Apr 2013 14:24:50 -0700
From: Tejun Heo <htejun@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: RongQing Li <roy.qing.li@...il.com>,
Shan Wei <davidshan@...cent.com>, netdev@...r.kernel.org,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PERCPU] Remove & in front of this_cpu_ptr
Hello, Christoph.
On Wed, Apr 03, 2013 at 08:42:33PM +0000, Christoph Lameter wrote:
> Subject: percpu: Remove & in front of this_cpu_ptr
>
> Both
>
> this_cpu_ptr(&percpu_pointer->field)
>
>
> [Add Offset in percpu pointer to the field offset in the struct
> and then add to the local percpu base]
>
> as well as
>
> &this_cpu_ptr(percpu_pointer)->field
>
> [Add percpu variable offset to local percpu base to form an address
> and then add the field offset to the address].
>
> are correct. However, the latter looks a bit more complicated.
> The first one is easier to understand. The second one may be
> more difficult for the compiler to optimize as well.
I don't know about this one. I actually prefer the latter in that the
pointer being passed into this_cpu_ptr() is something which is the
actual percpu pointer either from variable declaration or the
allocator. Sure, they both are just different expressions of the same
thing but the former requires an extra guarantee from percpu subsystem
that the accessors would work for pointers which aren't the exact
values defined or allocated. I'd much prefer unfiying things toward
the latter than the former.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists