From: Andi Kleen <ak@suse.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Paul Mackerras <paulus@samba.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Martin Mares <mj@atrey.karlin.mff.cuni.cz>,
bjornw@axis.com, schwidefsky@de.ibm.com, lethal@linux-sh.org,
Chris Zankel <chris@zankel.net>,
Marc Gauthier <marc@tensilica.com>,
Joe Taylor <joe@tensilica.com>,
rth@twiddle.net, spyro@f2s.com, starvik@axis.com,
tony.luck@intel.com, linux-ia64@vger.kernel.org,
ralf@linux-mips.org, linux-mips@linux-mips.org,
grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
linuxppc-dev@ozlabs.org, linux390@de.ibm.com,
davem@davemloft.net, arnd@arndb.de, kenneth.w.chen@intel.com,
sam@ravnborg.org, clameter@sgi.com, kiran@scalex86.org
Subject: Re: [RFC PATCH 01/09] robust VM per_cpu core
Date: Wed, 17 May 2006 11:08:54 +0000 [thread overview]
Message-ID: <200605171308.56203.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0605170640280.8408@gandalf.stny.rr.com>
On Wednesday 17 May 2006 12:46, Steven Rostedt wrote:
>
> On Wed, 17 May 2006, Andi Kleen wrote:
>
> >
> > > As well as the following three functions:
> > >
> > > pud_t *pud_boot_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long addr,
> > > int cpu);
> > > pmd_t *pmd_boot_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr,
> > > int cpu);
> > > pte_t *pte_boot_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long addr,
> > > int cpu);
> >
> > I'm not sure you can just put them like this into generic code. Some
> > architectures are doing strange things with them.
>
> Hmm, like what?
Mostly managing their software TLBs I think.
> >
> > And we already have boot_ioremap on some architectures. Why is that not
> > enough?
>
> I thought about using boot_ioremap, but it seems to be an abuse. Since
> I'm not mapping io, but actual memory pages.
We already use it for memory, e.g. for mapping some BIOS tables.
> So the solution to that
> seemed more of a hack. I then would need to worry about grabbing pages
> that were node specific
alloc_bootmem_node
> and getting the physical addresses.
virt_to_phys()
[ + hacks to handle 32bit NUMA unfortunately ]
-Andi
next prev parent reply other threads:[~2006-05-17 11:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-17 9:54 [RFC PATCH 00/09] robust VM per_cpu variables Steven Rostedt
2006-05-17 9:56 ` [RFC PATCH 01/09] robust VM per_cpu core Steven Rostedt
2006-05-17 9:17 ` Andi Kleen
2006-05-17 10:46 ` Steven Rostedt
2006-05-17 11:08 ` Andi Kleen [this message]
2006-05-17 11:31 ` Steven Rostedt
2006-05-17 9:56 ` [RFC PATCH 01/09] robust VM per_cpu mm header update Steven Rostedt
2006-05-17 9:57 ` [RFC PATCH 03/09] robust VM per_cpu generic header Steven Rostedt
2006-05-17 9:58 ` [RFC PATCH 04/09] robust VM per_cpu main startup Steven Rostedt
2006-05-17 9:59 ` [RFC PATCH 05/09] robust VM per_cpu module Steven Rostedt
2006-05-17 10:00 ` [RFC PATCH 06/09] robust VM per_cpu i386 bootmem Steven Rostedt
2006-05-17 10:01 ` [RFC PATCH 07/09] robust VM per_cpu i386 VM area Steven Rostedt
2006-05-17 10:01 ` [RFC PATCH 08/09] robust VM per_cpu i386 header Steven Rostedt
2006-05-17 10:01 ` [RFC PATCH 09/09] robust VM per_cpu i386 Kconfig update Steven Rostedt
2006-05-17 14:52 ` [RFC PATCH 00/09] robust VM per_cpu variables Christoph Lameter
2006-05-17 15:18 ` Steven Rostedt
2006-05-17 15:49 ` Christoph Lameter
2006-05-17 15:56 ` Steven Rostedt
2006-05-17 17:40 ` Christoph Lameter
2006-05-18 7:00 ` Steven Rostedt
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=200605171308.56203.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arnd@arndb.de \
--cc=bjornw@axis.com \
--cc=chris@zankel.net \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=grundler@parisc-linux.org \
--cc=joe@tensilica.com \
--cc=kenneth.w.chen@intel.com \
--cc=kiran@scalex86.org \
--cc=lethal@linux-sh.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux390@de.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=marc@tensilica.com \
--cc=mingo@elte.hu \
--cc=mj@atrey.karlin.mff.cuni.cz \
--cc=nickpiggin@yahoo.com.au \
--cc=parisc-linux@parisc-linux.org \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rostedt@goodmis.org \
--cc=rth@twiddle.net \
--cc=rusty@rustcorp.com.au \
--cc=sam@ravnborg.org \
--cc=schwidefsky@de.ibm.com \
--cc=spyro@f2s.com \
--cc=starvik@axis.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox