From: Tejun Heo <htejun@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: RongQing Li <roy.qing.li@gmail.com>,
Shan Wei <davidshan@tencent.com>,
netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PERCPU] Remove & in front of this_cpu_ptr
Date: Wed, 3 Apr 2013 14:24:50 -0700 [thread overview]
Message-ID: <20130403212450.GD3411@htj.dyndns.org> (raw)
In-Reply-To: <0000013dd1a300fb-1fbb26a9-77a7-4c24-95ff-f088309206d9-000000@email.amazonses.com>
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
next prev parent reply other threads:[~2013-04-03 21:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 9:42 [PATCH] core: fix the use of this_cpu_ptr roy.qing.li
2013-03-28 13:05 ` Eric Dumazet
2013-03-28 14:38 ` Christoph Lameter
2013-03-28 15:36 ` Eric Dumazet
2013-03-28 16:44 ` Christoph Lameter
2013-03-29 1:24 ` RongQing Li
2013-04-01 15:21 ` Christoph Lameter
2013-04-01 16:31 ` Eric Dumazet
2013-04-01 18:15 ` Christoph Lameter
2013-04-03 20:41 ` this cpu documentation Christoph Lameter
2013-04-03 21:18 ` Tejun Heo
2013-04-04 0:09 ` Randy Dunlap
2013-04-04 14:41 ` Christoph Lameter
2013-04-04 16:28 ` Tejun Heo
2013-04-04 17:19 ` Randy Dunlap
2013-04-04 17:26 ` Tejun Heo
2013-04-04 17:40 ` Christoph Lameter
2013-04-04 18:35 ` Randy Dunlap
2013-04-04 18:52 ` Tejun Heo
2013-04-11 17:00 ` Paul E. McKenney
[not found] ` <alpine.DEB.2.02.1304031540110.3444@gentwo.org>
2013-04-03 20:42 ` [PERCPU] Remove & in front of this_cpu_ptr Christoph Lameter
2013-04-03 21:24 ` Tejun Heo [this message]
2013-04-03 21:29 ` Eric Dumazet
2013-04-04 13:52 ` Christoph Lameter
2013-04-04 14:00 ` Tejun Heo
2013-04-04 14:21 ` Christoph Lameter
2013-04-04 14:25 ` Tejun Heo
2013-04-04 15:02 ` Christoph Lameter
2013-04-04 14:29 ` Eric Dumazet
2013-03-29 19:13 ` [PATCH] core: fix the use " David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130403212450.GD3411@htj.dyndns.org \
--to=htejun@gmail.com \
--cc=cl@linux.com \
--cc=davidshan@tencent.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=roy.qing.li@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).