From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Lameter <cl@linux-foundation.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: percpu tree build warning
Date: Fri, 27 Nov 2009 15:31:00 +0900 [thread overview]
Message-ID: <4B0F7224.9020509@kernel.org> (raw)
In-Reply-To: <20091127062001.GA22149@elte.hu>
Hello, Ingo.
> At least to me a typo like this would stick out like a sore thumb during
> review.
Yeah, maybe, but it still shows why reusing the same name for global
and local variables behind compiler's back is a bad idea.
> I'd recognize ®1 as a stack local variable immediately, and when i
> see it being used in this_cpu_inc() i'd go 'huh' immediately.
>
> OTOH, the two examples of confusion i gave you in my previous mail would
> be far less obvious. The 'visual distance' to a percpu variable
> definition is greater (it's at least file scope in 95% of the cases), so
> i wouldnt be able to 'see' which the percpu variables are, from a code
> context.
With proper __percpu annotations (which we desparately need for
dynamic percpu pointers anyway) the 'visual distance' should remain
fine in most cases, I think.
If we can manage the separate namespace thing without adding confusion
regarding different types of accessors and the actually non-existing
but yet visible differences between static and dynamic percpu
variables, I think it would be good. But it costs us quite a bit and
__percpu sparse annotation has almost complete coverage over the issue
including the visible queue telling that something is percpu. So,
given that, to me __percpu seems like a much better way to do it.
Thanks.
--
tejun
next prev parent reply other threads:[~2009-11-27 6:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 10:42 linux-next: percpu tree build warning Stephen Rothwell
2009-11-25 10:50 ` Ingo Molnar
2009-11-25 11:14 ` Rusty Russell
2009-11-25 11:58 ` Ingo Molnar
2009-11-25 12:39 ` Tejun Heo
2009-11-25 13:42 ` [tip:perf/core] x86: Rename global percpu symbol dr7 to cpu_dr7 tip-bot for Tejun Heo
2009-11-25 12:31 ` linux-next: percpu tree build warning Tejun Heo
2009-11-25 13:40 ` Ingo Molnar
2009-11-25 15:12 ` Tejun Heo
2009-11-26 22:16 ` Rusty Russell
2009-11-27 5:41 ` Ingo Molnar
2009-11-27 5:57 ` Tejun Heo
2009-11-27 6:20 ` Ingo Molnar
2009-11-27 6:31 ` Tejun Heo [this message]
2009-11-27 6:32 ` Tejun Heo
2009-11-28 9:51 ` Rusty Russell
2009-11-29 6:40 ` Ingo Molnar
2009-11-30 0:31 ` Rusty Russell
2009-11-25 13:24 ` [PATCH] x86: rename global percpu symbol dr7 to cpu_dr7 Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2009-11-12 6:45 linux-next: percpu tree build warning Stephen Rothwell
2009-11-12 15:16 ` Christoph Lameter
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=4B0F7224.9020509@kernel.org \
--to=tj@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.