public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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

  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