Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator

From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	rusty@rustcorp.com.au, tglx@linutronix.de, x86@kernel.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	Paul Mundt <lethal@linux-sh.org>,
	rmk@arm.linux.org.uk, starvik@axis.com, ralf@linux-mips.org,
	davem@davemloft.net, cooloney@kernel.org, kyle@mcmartin.ca,
	matthew@wil.cx, grundler@parisc-linux.org, takata@linux-m32r.org,
	benh@kernel.crashing.org, rth@twiddle.net,
	ink@jurassic.park.msu.ru, heiko.carstens@de.ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator
Date: Wed, 1 Apr 2009 13:07:31 +0200	[thread overview]
Message-ID: <20090401130731.785714c5@skybase> (raw)
In-Reply-To: <49D32B96.3060102@kernel.org>

On Wed, 01 Apr 2009 17:53:42 +0900
Tejun Heo <tj@kernel.org> wrote:

> Hello, Martin.
> 
> Martin Schwidefsky wrote:
> > Yes, @GOTENT is a relocation against the GOT slot that contains the
> > address of the symbol. It is a special version of @GOT that uses larl
> > to locate the got slot directly without the need of a got base pointer.
> > 
> > The code sequence with @GOT:
> > 
> > 	larl	%r12,_GLOBAL_OFFSET_TABLE_
> > 	lg	%r1,symbol@GOT(%r12)
> > 
> > is equivalent to:
> > 
> > 	larl	%r1,symbol@GOTENT
> > 	lg	%r1,0(%r1)
> > 
> > The advantage of the second code sequence is that it need a single
> > register and the size of the GOT is not limited to 4K as in the first
> > example (the offset in an RX format instruction is limited to 12 bits -
> > but that is probably something you don't want to know ;-).
> 
> Maybe we can build indirection pointer manually by twiddling with
> DEFINE_PER_CPU() in such a way that it doesn't have to distinguish
> symbols and variables?

Hmm, a provocative idea: can we ban the use of static per-cpu variables
for modules in common code? There are not many common code modules
doing this, with a visibility hack I found the following relevant
locations:

block/as-iosched.c:152: warning: 'visibility' attribute ignored
crypto/sha512_generic.c:30: warning: 'visibility' attribute ignored
block/cfq-iosched.c:51: warning: 'visibility' attribute ignored
mm/kmemleak-test.c:39: warning: 'visibility' attribute ignored
kernel/rcutorture.c:117: warning: 'visibility' attribute ignored
kernel/rcutorture.c:119: warning: 'visibility' attribute ignored
drivers/acpi/processor_core.c:663: warning: 'visibility' attribute ignored
drivers/acpi/processor_thermal.c:99: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_stats.c:46: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:30: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:31: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:32: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:33: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_userspace.c:35: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_ondemand.c:90: warning: 'visibility' attribute ignored
drivers/cpufreq/cpufreq_conservative.c:83: warning: 'visibility' attribute igno\
red
drivers/cpufreq/freq_table.c:177: warning: 'visibility' attribute ignored
net/ipv6/syncookies.c:77: warning: 'visibility' attribute ignored

That would "fix" the problem as well..

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.