From: Arnd Bergmann <arnd@arndb•de>
To: Steven Rostedt <rostedt@goodmis•org>
Cc: Andrew Morton <akpm@osdl•org>,
linux-mips@linux-mips•org,
David Mosberger-Tang <davidm@hpl•hp.com>,
linux-ia64@vger•kernel.org,
Martin Mares <mj@atrey•karlin.mff.cuni.cz>,
spyro@f2s•com, Joe Taylor <joe@tensilica•com>,
Andi Kleen <ak@suse•de>,
linuxppc-dev@ozlabs•org, Paul Mackerras <paulus@samba•org>,
benedict.gaster@superh•com, bjornw@axis•com,
Ingo Molnar <mingo@elte•hu>,
Nick Piggin <nickpiggin@yahoo•com.au>,
grundler@parisc-linux•org, rusty@rustcorp•com.au,
starvik@axis•com, Linus Torvalds <torvalds@osdl•org>,
Thomas Gleixner <tglx@linutronix•de>,
rth@twiddle•net, Chris Zankel <chris@zankel•net>,
tony.luck@intel•com, LKML <linux-kernel@vger•kernel.org>,
ralf@linux-mips•org, Marc Gauthier <marc@tensilica•com>,
lethal@linux-sh•org, schwidefsky@de•ibm.com, linux390@de•ibm.com,
davem@davemloft•net, parisc-linux@parisc-linux•org
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
Date: Sun, 16 Apr 2006 17:34:18 +0200 [thread overview]
Message-ID: <200604161734.20256.arnd@arndb.de> (raw)
In-Reply-To: <1145194804.27407.103.camel@localhost.localdomain>
On Sunday 16 April 2006 15:40, Steven Rostedt wrote:
> I'll think more about this, but maybe someone else has some crazy ideas
> that can find a solution to this that is both fast and robust.
Ok, you asked for a crazy idea, you're going to get it ;-)
You could take a fixed range from the vmalloc area (e.g. 1MB per cpu)
and use that to remap pages on demand when you need per cpu data.
#define PER_CPU_BASE 0xe000000000000000UL /* arch dependant */
#define PER_CPU_SHIFT 0x100000UL
#define __per_cpu_offset(__cpu) (PER_CPU_BASE + PER_CPU_STRIDE * (__cpu))
#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset(cpu)))
#define __get_cpu_var(var) per_cpu(var, smp_processor_id())
This is a lot like the current sparc64 implementation already is.
The tricky part here is the remapping of pages. You'd need to
alloc_pages_node() new pages whenever the already reserved space is
not enough for the module you want to load and then map_vm_area()
them into the space reserved for them.
Advantages of this solution are:
- no dependant load access for per_cpu()
- might be flexible enough to implement a faster per_cpu_ptr()
- can be combined with ia64-style per-cpu remapping
Disadvantages are:
- you can't use huge tlbs for mapping per cpu data like the
regular linear mapping -> may be slower on some archs
- does not work in real mode, so percpu data can't be used
inside exception handlers on some architectures.
- memory consumption is rather high when PAGE_SIZE is large
Arnd <><
next prev parent reply other threads:[~2006-04-16 15:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-14 21:18 [PATCH 00/05] robust per_cpu allocation for modules Steven Rostedt
2006-04-14 22:06 ` Andrew Morton
2006-04-14 22:12 ` Steven Rostedt
2006-04-14 22:12 ` Chen, Kenneth W
2006-04-15 3:10 ` [PATCH 00/08] robust per_cpu allocation for modules - V2 Steven Rostedt
2006-04-15 5:32 ` [PATCH 00/05] robust per_cpu allocation for modules Nick Piggin
2006-04-15 20:17 ` Steven Rostedt
2006-04-16 2:47 ` Nick Piggin
2006-04-16 3:53 ` Steven Rostedt
2006-04-16 7:02 ` Paul Mackerras
2006-04-16 13:40 ` Steven Rostedt
2006-04-16 14:03 ` Sam Ravnborg
2006-04-16 15:34 ` Arnd Bergmann [this message]
2006-04-16 18:03 ` Tony Luck
2006-04-17 0:45 ` Steven Rostedt
2006-04-17 2:07 ` Arnd Bergmann
2006-04-17 2:17 ` Steven Rostedt
2006-04-17 20:06 ` Ravikiran G Thirumalai
2006-04-17 6:47 ` Rusty Russell
2006-04-17 11:33 ` Steven Rostedt
2006-04-16 7:06 ` Nick Piggin
2006-04-16 16:06 ` Steven Rostedt
2006-04-17 17:10 ` Andi Kleen
2006-04-17 16:55 ` Christoph Lameter
2006-04-17 22:02 ` Ravikiran G Thirumalai
2006-04-17 23:44 ` Steven Rostedt
2006-04-17 23:48 ` Christoph Lameter
2006-04-18 1:51 ` Steven Rostedt
2006-04-18 6:42 ` Nick Piggin
2006-04-18 12:47 ` Steven Rostedt
2006-04-16 6:35 ` Paul Mackerras
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=200604161734.20256.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=ak@suse$(echo .)de \
--cc=akpm@osdl$(echo .)org \
--cc=benedict.gaster@superh$(echo .)com \
--cc=bjornw@axis$(echo .)com \
--cc=chris@zankel$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=davidm@hpl$(echo .)hp.com \
--cc=grundler@parisc-linux$(echo .)org \
--cc=joe@tensilica$(echo .)com \
--cc=lethal@linux-sh$(echo .)org \
--cc=linux-ia64@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mips@linux-mips$(echo .)org \
--cc=linux390@de$(echo .)ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=marc@tensilica$(echo .)com \
--cc=mingo@elte$(echo .)hu \
--cc=mj@atrey$(echo .)karlin.mff.cuni.cz \
--cc=nickpiggin@yahoo$(echo .)com.au \
--cc=parisc-linux@parisc-linux$(echo .)org \
--cc=paulus@samba$(echo .)org \
--cc=ralf@linux-mips$(echo .)org \
--cc=rostedt@goodmis$(echo .)org \
--cc=rth@twiddle$(echo .)net \
--cc=rusty@rustcorp$(echo .)com.au \
--cc=schwidefsky@de$(echo .)ibm.com \
--cc=spyro@f2s$(echo .)com \
--cc=starvik@axis$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
--cc=tony.luck@intel$(echo .)com \
--cc=torvalds@osdl$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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