From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Date: Wed, 17 May 2006 11:08:54 +0000 Subject: Re: [RFC PATCH 01/09] robust VM per_cpu core Message-Id: <200605171308.56203.ak@suse.de> List-Id: References: <200605171117.06060.ak@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Steven Rostedt Cc: LKML , Rusty Russell , Paul Mackerras , Nick Piggin , Andrew Morton , Linus Torvalds , Ingo Molnar , Thomas Gleixner , Martin Mares , bjornw@axis.com, schwidefsky@de.ibm.com, lethal@linux-sh.org, Chris Zankel , Marc Gauthier , Joe Taylor , 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 17 May 2006 13:09:47 +0200 (CEST) Received: from mx2.suse.de ([195.135.220.15]:10389 "HELO mx2.suse.de") by ftp.linux-mips.org with SMTP id S8133729AbWEQLJi (ORCPT ); Wed, 17 May 2006 13:09:38 +0200 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 999E11CC33; Wed, 17 May 2006 13:09:15 +0200 (CEST) From: Andi Kleen To: Steven Rostedt Subject: Re: [RFC PATCH 01/09] robust VM per_cpu core Date: Wed, 17 May 2006 13:08:54 +0200 User-Agent: KMail/1.9.1 Cc: LKML , Rusty Russell , Paul Mackerras , Nick Piggin , Andrew Morton , Linus Torvalds , Ingo Molnar , Thomas Gleixner , Martin Mares , bjornw@axis.com, schwidefsky@de.ibm.com, lethal@linux-sh.org, Chris Zankel , Marc Gauthier , Joe Taylor , 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 References: <200605171117.06060.ak@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605171308.56203.ak@suse.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ak@suse.de Precedence: bulk X-list: linux-mips 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.suse.de", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 17BD767B1C for ; Wed, 17 May 2006 21:09:27 +1000 (EST) From: Andi Kleen To: Steven Rostedt Subject: Re: [RFC PATCH 01/09] robust VM per_cpu core Date: Wed, 17 May 2006 13:08:54 +0200 References: <200605171117.06060.ak@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200605171308.56203.ak@suse.de> Cc: Andrew Morton , linux-mips@linux-mips.org, linux-ia64@vger.kernel.org, Martin Mares , spyro@f2s.com, Joe Taylor , linuxppc-dev@ozlabs.org, Paul Mackerras , sam@ravnborg.org, bjornw@axis.com, kenneth.w.chen@intel.com, Ingo Molnar , kiran@scalex86.org, clameter@sgi.com, Nick Piggin , grundler@parisc-linux.org, arnd@arndb.de, Rusty Russell , starvik@axis.com, Linus Torvalds , Thomas Gleixner , rth@twiddle.net, Chris Zankel , tony.luck@intel.com, LKML , ralf@linux-mips.org, Marc Gauthier , lethal@linux-sh.org, schwidefsky@de.ibm.com, linux390@de.ibm.com, davem@davemloft.net, parisc-linux@parisc-linux.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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