[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49D41ABC.7070603@kernel.org>
Date: Thu, 02 Apr 2009 10:54:04 +0900
From: Tejun Heo <tj@...nel.org>
To: Martin Schwidefsky <schwidefsky@...ibm.com>
CC: David Miller <davem@...emloft.net>, mingo@...e.hu,
rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
linux-kernel@...r.kernel.org, hpa@...or.com, lethal@...ux-sh.org,
rmk@....linux.org.uk, starvik@...s.com, ralf@...ux-mips.org,
cooloney@...nel.org, kyle@...artin.ca, matthew@....cx,
grundler@...isc-linux.org, takata@...ux-m32r.org,
benh@...nel.crashing.org, rth@...ddle.net,
ink@...assic.park.msu.ru, heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
percpu allocator
Hello,
Martin Schwidefsky wrote:
>> Also, there is no guarantee that the offset from dynamic allocator
>> will fall in the same 4G. There is reserve mechanism for static ones
>> for archs which need it but for dynamic ones, the offset can be any
>> value.
>
> If we map the modules with a 4GB distance to the main kernel image then
> we don't have to worry about the offsets anymore. The compiler could
> just use LARL to get the address of the static per-cpu variables and
> SHIFT_PERCPU_PTR could be a RELOC_HIDE.
Ah... okay. Great. No more GOTENT trick for static ones and for
dynamic ones the compiler will generate indirection.
> It just that the remapping we need to do is sooo icky ..
Fingers and toes crossed. It would improve general percpu access
performance too.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists