Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [RFC PATCH 01/09] robust VM per_cpu core | Date | Wed, 17 May 2006 13:08:54 +0200 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |