2005-09-26 06:04:21 +00:00
|
|
|
/*
|
|
|
|
* PowerPC version
|
|
|
|
* Copyright (C) 1995-1996 Gary Thomas (gdt@linuxppc.org)
|
|
|
|
*
|
|
|
|
* Modifications by Paul Mackerras (PowerMac) (paulus@cs.anu.edu.au)
|
|
|
|
* and Cort Dougan (PReP) (cort@cs.nmt.edu)
|
|
|
|
* Copyright (C) 1996 Paul Mackerras
|
|
|
|
*
|
|
|
|
* Derived from "arch/i386/mm/init.c"
|
|
|
|
* Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds
|
|
|
|
*
|
|
|
|
* Dave Engebretsen <engebret@us.ibm.com>
|
|
|
|
* Rework for PPC64 port.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 05:41:48 +00:00
|
|
|
#undef DEBUG
|
|
|
|
|
2005-09-26 06:04:21 +00:00
|
|
|
#include <linux/signal.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/stddef.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/bootmem.h>
|
|
|
|
#include <linux/highmem.h>
|
|
|
|
#include <linux/idr.h>
|
|
|
|
#include <linux/nodemask.h>
|
|
|
|
#include <linux/module.h>
|
2006-06-27 09:53:52 +00:00
|
|
|
#include <linux/poison.h>
|
2008-02-14 00:56:49 +00:00
|
|
|
#include <linux/lmb.h>
|
powerpc/mm: Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing "special" hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-10-26 19:24:31 +00:00
|
|
|
#include <linux/hugetlb.h>
|
2005-09-26 06:04:21 +00:00
|
|
|
|
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/page.h>
|
|
|
|
#include <asm/prom.h>
|
|
|
|
#include <asm/rtas.h>
|
|
|
|
#include <asm/io.h>
|
|
|
|
#include <asm/mmu_context.h>
|
|
|
|
#include <asm/pgtable.h>
|
|
|
|
#include <asm/mmu.h>
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
#include <asm/smp.h>
|
|
|
|
#include <asm/machdep.h>
|
|
|
|
#include <asm/tlb.h>
|
|
|
|
#include <asm/eeh.h>
|
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/mmzone.h>
|
|
|
|
#include <asm/cputable.h>
|
|
|
|
#include <asm/sections.h>
|
|
|
|
#include <asm/system.h>
|
|
|
|
#include <asm/iommu.h>
|
|
|
|
#include <asm/abs_addr.h>
|
|
|
|
#include <asm/vdso.h>
|
2005-11-16 04:43:48 +00:00
|
|
|
|
|
|
|
#include "mmu_decl.h"
|
2005-09-26 06:04:21 +00:00
|
|
|
|
2009-06-02 21:17:45 +00:00
|
|
|
#ifdef CONFIG_PPC_STD_MMU_64
|
2005-09-26 06:04:21 +00:00
|
|
|
#if PGTABLE_RANGE > USER_VSID_RANGE
|
|
|
|
#warning Limited user VSID range means pagetable space is wasted
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if (TASK_SIZE_USER64 < PGTABLE_RANGE) && (TASK_SIZE_USER64 < USER_VSID_RANGE)
|
|
|
|
#warning TASK_SIZE is smaller than it needs to be.
|
|
|
|
#endif
|
2009-06-02 21:17:45 +00:00
|
|
|
#endif /* CONFIG_PPC_STD_MMU_64 */
|
2005-09-26 06:04:21 +00:00
|
|
|
|
2008-04-21 18:22:34 +00:00
|
|
|
phys_addr_t memstart_addr = ~0;
|
|
|
|
phys_addr_t kernstart_addr;
|
2008-04-15 19:52:22 +00:00
|
|
|
|
2005-09-26 06:04:21 +00:00
|
|
|
void free_initmem(void)
|
|
|
|
{
|
|
|
|
unsigned long addr;
|
|
|
|
|
|
|
|
addr = (unsigned long)__init_begin;
|
|
|
|
for (; addr < (unsigned long)__init_end; addr += PAGE_SIZE) {
|
2006-06-27 09:53:52 +00:00
|
|
|
memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
|
2005-09-26 06:04:21 +00:00
|
|
|
ClearPageReserved(virt_to_page(addr));
|
2006-03-22 08:08:40 +00:00
|
|
|
init_page_count(virt_to_page(addr));
|
2005-09-26 06:04:21 +00:00
|
|
|
free_page(addr);
|
|
|
|
totalram_pages++;
|
|
|
|
}
|
|
|
|
printk ("Freeing unused kernel memory: %luk freed\n",
|
|
|
|
((unsigned long)__init_end - (unsigned long)__init_begin) >> 10);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_BLK_DEV_INITRD
|
|
|
|
void free_initrd_mem(unsigned long start, unsigned long end)
|
|
|
|
{
|
|
|
|
if (start < end)
|
|
|
|
printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
|
|
|
|
for (; start < end; start += PAGE_SIZE) {
|
|
|
|
ClearPageReserved(virt_to_page(start));
|
2006-03-22 08:08:40 +00:00
|
|
|
init_page_count(virt_to_page(start));
|
2005-09-26 06:04:21 +00:00
|
|
|
free_page(start);
|
|
|
|
totalram_pages++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-07-26 02:45:34 +00:00
|
|
|
static void pgd_ctor(void *addr)
|
2005-09-26 06:04:21 +00:00
|
|
|
{
|
2008-07-26 02:45:34 +00:00
|
|
|
memset(addr, 0, PGD_TABLE_SIZE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pmd_ctor(void *addr)
|
|
|
|
{
|
|
|
|
memset(addr, 0, PMD_TABLE_SIZE);
|
2005-09-26 06:04:21 +00:00
|
|
|
}
|
|
|
|
|
2009-10-28 16:27:18 +00:00
|
|
|
struct kmem_cache *pgtable_cache[MAX_PGTABLE_INDEX_SIZE];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a kmem_cache() for pagetables. This is not used for PTE
|
|
|
|
* pages - they're linked to struct page, come from the normal free
|
|
|
|
* pages pool and have a different entry size (see real_pte_t) to
|
|
|
|
* everything else. Caches created by this function are used for all
|
|
|
|
* the higher level pagetables, and for hugepage pagetables.
|
|
|
|
*/
|
|
|
|
void pgtable_cache_add(unsigned shift, void (*ctor)(void *))
|
|
|
|
{
|
|
|
|
char *name;
|
|
|
|
unsigned long table_size = sizeof(void *) << shift;
|
|
|
|
unsigned long align = table_size;
|
|
|
|
|
|
|
|
/* When batching pgtable pointers for RCU freeing, we store
|
|
|
|
* the index size in the low bits. Table alignment must be
|
powerpc/mm: Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing "special" hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-10-26 19:24:31 +00:00
|
|
|
* big enough to fit it.
|
|
|
|
*
|
|
|
|
* Likewise, hugeapge pagetable pointers contain a (different)
|
|
|
|
* shift value in the low bits. All tables must be aligned so
|
|
|
|
* as to leave enough 0 bits in the address to contain it. */
|
|
|
|
unsigned long minalign = max(MAX_PGTABLE_INDEX_SIZE + 1,
|
|
|
|
HUGEPD_SHIFT_MASK + 1);
|
2009-10-28 16:27:18 +00:00
|
|
|
struct kmem_cache *new;
|
|
|
|
|
|
|
|
/* It would be nice if this was a BUILD_BUG_ON(), but at the
|
|
|
|
* moment, gcc doesn't seem to recognize is_power_of_2 as a
|
|
|
|
* constant expression, so so much for that. */
|
|
|
|
BUG_ON(!is_power_of_2(minalign));
|
|
|
|
BUG_ON((shift < 1) || (shift > MAX_PGTABLE_INDEX_SIZE));
|
|
|
|
|
|
|
|
if (PGT_CACHE(shift))
|
|
|
|
return; /* Already have a cache of this size */
|
|
|
|
|
|
|
|
align = max_t(unsigned long, align, minalign);
|
|
|
|
name = kasprintf(GFP_KERNEL, "pgtable-2^%d", shift);
|
|
|
|
new = kmem_cache_create(name, table_size, align, 0, ctor);
|
|
|
|
PGT_CACHE(shift) = new;
|
|
|
|
|
|
|
|
pr_debug("Allocated pgtable cache for order %d\n", shift);
|
|
|
|
}
|
|
|
|
|
2005-09-26 06:04:21 +00:00
|
|
|
|
|
|
|
void pgtable_cache_init(void)
|
|
|
|
{
|
2009-10-28 16:27:18 +00:00
|
|
|
pgtable_cache_add(PGD_INDEX_SIZE, pgd_ctor);
|
|
|
|
pgtable_cache_add(PMD_INDEX_SIZE, pmd_ctor);
|
|
|
|
if (!PGT_CACHE(PGD_INDEX_SIZE) || !PGT_CACHE(PMD_INDEX_SIZE))
|
|
|
|
panic("Couldn't allocate pgtable caches");
|
|
|
|
|
|
|
|
/* In all current configs, when the PUD index exists it's the
|
|
|
|
* same size as either the pgd or pmd index. Verify that the
|
|
|
|
* initialization above has also created a PUD cache. This
|
|
|
|
* will need re-examiniation if we add new possibilities for
|
|
|
|
* the pagetable layout. */
|
|
|
|
BUG_ON(PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE));
|
2005-09-26 06:04:21 +00:00
|
|
|
}
|
2007-10-16 08:24:17 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
/*
|
|
|
|
* Given an address within the vmemmap, determine the pfn of the page that
|
|
|
|
* represents the start of the section it is within. Note that we have to
|
|
|
|
* do this by hand as the proffered address may not be correctly aligned.
|
|
|
|
* Subtraction of non-aligned pointers produces undefined results.
|
|
|
|
*/
|
2008-05-08 04:27:07 +00:00
|
|
|
static unsigned long __meminit vmemmap_section_start(unsigned long page)
|
2007-10-16 08:24:17 +00:00
|
|
|
{
|
|
|
|
unsigned long offset = page - ((unsigned long)(vmemmap));
|
|
|
|
|
|
|
|
/* Return the pfn of the start of the section. */
|
|
|
|
return (offset / sizeof(struct page)) & PAGE_SECTION_MASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if this vmemmap page is already initialised. If any section
|
|
|
|
* which overlaps this vmemmap page is initialised then this page is
|
|
|
|
* initialised already.
|
|
|
|
*/
|
2008-05-08 04:27:07 +00:00
|
|
|
static int __meminit vmemmap_populated(unsigned long start, int page_size)
|
2007-10-16 08:24:17 +00:00
|
|
|
{
|
|
|
|
unsigned long end = start + page_size;
|
|
|
|
|
|
|
|
for (; start < end; start += (PAGES_PER_SECTION * sizeof(struct page)))
|
|
|
|
if (pfn_valid(vmemmap_section_start(start)))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-07-23 23:15:58 +00:00
|
|
|
/* On hash-based CPUs, the vmemmap is bolted in the hash table.
|
|
|
|
*
|
|
|
|
* On Book3E CPUs, the vmemmap is currently mapped in the top half of
|
|
|
|
* the vmalloc space using normal page tables, though the size of
|
|
|
|
* pages encoded in the PTEs can be different
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef CONFIG_PPC_BOOK3E
|
|
|
|
static void __meminit vmemmap_create_mapping(unsigned long start,
|
|
|
|
unsigned long page_size,
|
|
|
|
unsigned long phys)
|
|
|
|
{
|
|
|
|
/* Create a PTE encoding without page size */
|
|
|
|
unsigned long i, flags = _PAGE_PRESENT | _PAGE_ACCESSED |
|
|
|
|
_PAGE_KERNEL_RW;
|
|
|
|
|
|
|
|
/* PTEs only contain page size encodings up to 32M */
|
|
|
|
BUG_ON(mmu_psize_defs[mmu_vmemmap_psize].enc > 0xf);
|
|
|
|
|
|
|
|
/* Encode the size in the PTE */
|
|
|
|
flags |= mmu_psize_defs[mmu_vmemmap_psize].enc << 8;
|
|
|
|
|
|
|
|
/* For each PTE for that area, map things. Note that we don't
|
|
|
|
* increment phys because all PTEs are of the large size and
|
|
|
|
* thus must have the low bits clear
|
|
|
|
*/
|
|
|
|
for (i = 0; i < page_size; i += PAGE_SIZE)
|
|
|
|
BUG_ON(map_kernel_page(start + i, phys, flags));
|
|
|
|
}
|
|
|
|
#else /* CONFIG_PPC_BOOK3E */
|
|
|
|
static void __meminit vmemmap_create_mapping(unsigned long start,
|
|
|
|
unsigned long page_size,
|
|
|
|
unsigned long phys)
|
|
|
|
{
|
|
|
|
int mapped = htab_bolt_mapping(start, start + page_size, phys,
|
|
|
|
PAGE_KERNEL, mmu_vmemmap_psize,
|
|
|
|
mmu_kernel_ssize);
|
|
|
|
BUG_ON(mapped < 0);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PPC_BOOK3E */
|
|
|
|
|
2007-10-16 08:24:17 +00:00
|
|
|
int __meminit vmemmap_populate(struct page *start_page,
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 05:41:48 +00:00
|
|
|
unsigned long nr_pages, int node)
|
2007-10-16 08:24:17 +00:00
|
|
|
{
|
|
|
|
unsigned long start = (unsigned long)start_page;
|
|
|
|
unsigned long end = (unsigned long)(start_page + nr_pages);
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 05:41:48 +00:00
|
|
|
unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
|
2007-10-16 08:24:17 +00:00
|
|
|
|
|
|
|
/* Align to the page size of the linear mapping. */
|
|
|
|
start = _ALIGN_DOWN(start, page_size);
|
|
|
|
|
2009-07-23 23:15:58 +00:00
|
|
|
pr_debug("vmemmap_populate page %p, %ld pages, node %d\n",
|
|
|
|
start_page, nr_pages, node);
|
|
|
|
pr_debug(" -> map %lx..%lx\n", start, end);
|
|
|
|
|
2007-10-16 08:24:17 +00:00
|
|
|
for (; start < end; start += page_size) {
|
|
|
|
void *p;
|
|
|
|
|
|
|
|
if (vmemmap_populated(start, page_size))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
p = vmemmap_alloc_block(page_size, node);
|
|
|
|
if (!p)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2009-07-23 23:15:58 +00:00
|
|
|
pr_debug(" * %016lx..%016lx allocated at %p\n",
|
|
|
|
start, start + page_size, p);
|
2007-10-16 08:24:17 +00:00
|
|
|
|
2009-07-23 23:15:58 +00:00
|
|
|
vmemmap_create_mapping(start, page_size, __pa(p));
|
2007-10-16 08:24:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 05:41:48 +00:00
|
|
|
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
|