x86, mm, 64bit: Put early page table high.
Subsystems (4)
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/3 x86, mm, 64bit: Put early page table high.
While dubug kdump, found current kernel will have problem with crashkernel=512M.
It turns out that initial mapping is to 512M, and later initial mapping to 4G (acutally is 2040M in my platform), will put page table near 512M. then initial mapping to 128g will be near 2g.
before this patch:
[ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] init_memory_mapping: [0x00000000000000-0x0000007f74ffff] [ 0.000000] 0000000000 - 007f600000 page 2M [ 0.000000] 007f600000 - 007f750000 page 4k [ 0.000000] kernel direct mapping tables up to 7f750000 @ [0x1fffc000-0x1fffffff] [ 0.000000] memblock_x86_reserve_range: [0x1fffc000-0x1fffdfff] PGTABLE [ 0.000000] init_memory_mapping: [0x00000100000000-0x0000207fffffff] [ 0.000000] 0100000000 - 2080000000 page 2M [ 0.000000] kernel direct mapping tables up to 2080000000 @ [0x7bc01000-0x7bc83fff] [ 0.000000] memblock_x86_reserve_range: [0x7bc01000-0x7bc7efff] PGTABLE [ 0.000000] RAMDISK: 7bc84000 - 7f745000 [ 0.000000] crashkernel reservation failed - No suitable area found.
after patch:
[ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] init_memory_mapping: [0x00000000000000-0x0000007f74ffff] [ 0.000000] 0000000000 - 007f600000 page 2M [ 0.000000] 007f600000 - 007f750000 page 4k [ 0.000000] kernel direct mapping tables up to 7f750000 @ [0x7f74c000-0x7f74ffff] [ 0.000000] memblock_x86_reserve_range: [0x7f74c000-0x7f74dfff] PGTABLE [ 0.000000] init_memory_mapping: [0x00000100000000-0x0000207fffffff] [ 0.000000] 0100000000 - 2080000000 page 2M [ 0.000000] kernel direct mapping tables up to 2080000000 @ [0x207ff7d000-0x207fffffff] [ 0.000000] memblock_x86_reserve_range: [0x207ff7d000-0x207fffafff] PGTABLE [ 0.000000] RAMDISK: 7bc84000 - 7f745000 [ 0.000000] memblock_x86_reserve_range: [0x17000000-0x36ffffff] CRASH KERNEL [ 0.000000] Reserving 512MB of memory at 368MB for crashkernel (System RAM: 133120MB)
It means with the patch, page table for [0, 2g) will need 2g, instead of under 512M, page table for [4g, 128g) will be near 128g, instead of under 2g.
That would good, if we have lots of memory above 4g, like 1024g, or 2048g or 16T, will not put related page table under 2g. that would be have chance to fill the under 2g if 1G or 2M page is not used.
the code change will use add map_low_page() and update unmap_low_page() for 64bit, and use them to get access the corresponding high memory for page table setting.
Signed-off-by Yinghai Lu <[email protected]>
--- arch/x86/mm/init.c | 9 ++----- arch/x86/mm/init_64.c | 63 +++++++++++++++++++++----------------------------- 2 files changed, 30 insertions(+), 42 deletions(-)
arch/x86/mm/init.c +3 -6
@@ -33,7 +33,7 @@ int direct_gbpagesstatic void __init find_early_table_space (unsigned long end,int use_pse,int use_gbpages) { -unsigned long puds, pmds, ptes, tables, start; +unsigned long puds, pmds, ptes, tables, start =0 , good_end = end;phys_addr_t base; puds = (end +PUD_SIZE -1 ) >>PUD_SHIFT ;
@@ -73,12 +73,9 @@ static void __init find_early_table_spac* need roughly 0.5KB per GB. */ #ifdef CONFIG_X86_32 - start =0x7000 ; -#else - start =0x8000 ; + good_end = max_pfn_mapped <<PAGE_SHIFT ;#endif - base =memblock_find_in_range (start, max_pfn_mapped<<PAGE_SHIFT , - tables,PAGE_SIZE ); + base =memblock_find_in_range (start, good_end, tables,PAGE_SIZE );if (base ==MEMBLOCK_ERROR )panic ("Cannot find space for the kernel page tables" );
arch/x86/mm/init_64.c +27 -36
113 lines not on this page · raw message
[tip:x86/mm] x86-64, mm: Put early page table high
Commit-ID: 4b239f458c229de044d6905c2b0f9fe16ed9e01e Gitweb: http://git.kernel.org/tip/4b239f458c229de044d6905c2b0f9fe16ed9e01e Author: Yinghai Lu <[email protected]> AuthorDate: Fri, 17 Dec 2010 16:58:28 -0800 Committer: H. Peter Anvin <[email protected]> CommitDate: Wed, 29 Dec 2010 14:46:54 -0800
x86-64, mm: Put early page table high
While dubug kdump, found current kernel will have problem with crashkernel=512M.
It turns out that initial mapping is to 512M, and later initial mapping to 4G (acutally is 2040M in my platform), will put page table near 512M. then initial mapping to 128g will be near 2g.
before this patch:
[ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] init_memory_mapping: [0x00000000000000-0x0000007f74ffff] [ 0.000000] 0000000000 - 007f600000 page 2M [ 0.000000] 007f600000 - 007f750000 page 4k [ 0.000000] kernel direct mapping tables up to 7f750000 @ [0x1fffc000-0x1fffffff] [ 0.000000] memblock_x86_reserve_range: [0x1fffc000-0x1fffdfff] PGTABLE [ 0.000000] init_memory_mapping: [0x00000100000000-0x0000207fffffff] [ 0.000000] 0100000000 - 2080000000 page 2M [ 0.000000] kernel direct mapping tables up to 2080000000 @ [0x7bc01000-0x7bc83fff] [ 0.000000] memblock_x86_reserve_range: [0x7bc01000-0x7bc7efff] PGTABLE [ 0.000000] RAMDISK: 7bc84000 - 7f745000 [ 0.000000] crashkernel reservation failed - No suitable area found.
after patch:
[ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] init_memory_mapping: [0x00000000000000-0x0000007f74ffff] [ 0.000000] 0000000000 - 007f600000 page 2M [ 0.000000] 007f600000 - 007f750000 page 4k [ 0.000000] kernel direct mapping tables up to 7f750000 @ [0x7f74c000-0x7f74ffff] [ 0.000000] memblock_x86_reserve_range: [0x7f74c000-0x7f74dfff] PGTABLE [ 0.000000] init_memory_mapping: [0x00000100000000-0x0000207fffffff] [ 0.000000] 0100000000 - 2080000000 page 2M [ 0.000000] kernel direct mapping tables up to 2080000000 @ [0x207ff7d000-0x207fffffff] [ 0.000000] memblock_x86_reserve_range: [0x207ff7d000-0x207fffafff] PGTABLE [ 0.000000] RAMDISK: 7bc84000 - 7f745000 [ 0.000000] memblock_x86_reserve_range: [0x17000000-0x36ffffff] CRASH KERNEL [ 0.000000] Reserving 512MB of memory at 368MB for crashkernel (System RAM: 133120MB)
It means with the patch, page table for [0, 2g) will need 2g, instead of under 512M, page table for [4g, 128g) will be near 128g, instead of under 2g.
That would good, if we have lots of memory above 4g, like 1024g, or 2048g or 16T, will not put related page table under 2g. that would be have chance to fill the under 2g if 1G or 2M page is not used.
the code change will use add map_low_page() and update unmap_low_page() for 64bit, and use them to get access the corresponding high memory for page table setting.
Signed-off-by Yinghai Lu <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by H. Peter Anvin <[email protected]>
--- arch/x86/mm/init.c | 9 ++---- arch/x86/mm/init_64.c | 63 +++++++++++++++++++++---------------------------- 2 files changed, 30 insertions(+), 42 deletions(-)
arch/x86/mm/init.c +3 -6
@@ -33,7 +33,7 @@ int direct_gbpagesstatic void __init find_early_table_space (unsigned long end,int use_pse,int use_gbpages) { -unsigned long puds, pmds, ptes, tables, start; +unsigned long puds, pmds, ptes, tables, start =0 , good_end = end;phys_addr_t base; puds = (end +PUD_SIZE -1 ) >>PUD_SHIFT ;
@@ -73,12 +73,9 @@ static void __init find_early_table_space(unsigned long end, int use_pse,* need roughly 0.5KB per GB. */ #ifdef CONFIG_X86_32 - start =0x7000 ; -#else - start =0x8000 ; + good_end = max_pfn_mapped <<PAGE_SHIFT ;#endif - base =memblock_find_in_range (start, max_pfn_mapped<<PAGE_SHIFT , - tables,PAGE_SIZE ); + base =memblock_find_in_range (start, good_end, tables,PAGE_SIZE );if (base ==MEMBLOCK_ERROR )panic ("Cannot find space for the kernel page tables" );
arch/x86/mm/init_64.c +27 -36
113 lines not on this page · raw message
PATCH 2/3 x86, 64bit, gart: Fix allocation with memblock
In reply to a message not in the archiveWhen trying to change alloc_bootmem with memblock to go with real top-down Found one old system:
[ 0.000000] Node 0: aperture @ ac000000 size 64 MB [ 0.000000] Aperture pointing to e820 RAM. Ignoring. [ 0.000000] Your BIOS doesn't leave a aperture memory hole [ 0.000000] Please enable the IOMMU option in the BIOS setup [ 0.000000] This costs you 64 MB of RAM [ 0.000000] memblock_x86_reserve_range: [0x2020000000-0x2023ffffff] aperture64 [ 0.000000] Cannot allocate aperture memory hole (ffff882020000000,65536K) [ 0.000000] memblock_x86_free_range: [0x2020000000-0x2023ffffff] [ 0.000000] Kernel panic - not syncing: Not enough memory for aperture [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.37-rc5-tip-yh-06229-gb792dc2-dirty #331 [ 0.000000] Call Trace: [ 0.000000] [<ffffffff81cf50fe>] ? panic+0x91/0x1a3 [ 0.000000] [<ffffffff827c66b2>] ? gart_iommu_hole_init+0x3d7/0x4a3 [ 0.000000] [<ffffffff81d026a9>] ? _etext+0x0/0x3 [ 0.000000] [<ffffffff827ba940>] ? pci_iommu_alloc+0x47/0x71 [ 0.000000] [<ffffffff827c820b>] ? mem_init+0x19/0xec [ 0.000000] [<ffffffff827b3c40>] ? start_kernel+0x20a/0x3e8 [ 0.000000] [<ffffffff827b32cc>] ? x86_64_start_reservations+0x9c/0xa0 [ 0.000000] [<ffffffff827b33e4>] ? x86_64_start_kernel+0x114/0x11b
it means __alloc_bootmem_nopanic() get too high for that aperture.
Use memblock_find_in_range() with limit directly.
Signed-off-by Yinghai Lu <[email protected]>
--- arch/x86/kernel/aperture_64.c | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-)
arch/x86/kernel/aperture_64.c +16 -17
@@ -13,7 +13,7 @@#include <linux/kernel.h> #include <linux/types.h> #include <linux/init.h> -#include <linux/bootmem.h> +#include <linux/memblock.h> #include <linux/mmzone.h> #include <linux/pci_ids.h> #include <linux/pci.h>
@@ -69,7 +69,7 @@ static void __init insert_aperture_resoustatic u32 __init allocate_aperture (void ) {u32 aper_size; -void *p; +unsigned long addr;/* aper_size should <= 1G */ if (fallback_aper_order >5 )
@@ -95,27 +95,26 @@ static u32 __init allocate_aperture(void* so don't use 512M below as gart iommu, leave the space for kernel * code for safe */ - p =__alloc_bootmem_nopanic (aper_size, aper_size,512ULL <<20 ); + addr =memblock_find_in_range (0 ,1ULL <<32 , aper_size,512ULL <<20 ); +if (addr ==MEMBLOCK_ERROR || addr + aper_size >0xffffffff ) { +printk (KERN_ERR +"Cannot allocate aperture memory hole (%lx,%uK)\n" , + addr, aper_size>>10 ); +return 0 ; + } +memblock_x86_reserve_range (addr, addr + aper_size,"aperture64" );/* * Kmemleak should not scan this block as it may not be mapped via the * kernel direct mapping. */ -kmemleak_ignore (p); -if (!p ||__pa (p)+aper_size >0xffffffff ) { -printk (KERN_ERR -"Cannot allocate aperture memory hole (%p,%uK)\n" , - p, aper_size>>10 ); -if (p) -free_bootmem (__pa (p), aper_size); -return 0 ; - } +kmemleak_ignore (phys_to_virt (addr));printk (KERN_INFO "Mapping aperture over %d KB of RAM @ %lx\n" , - aper_size >>10 ,__pa (p)); -insert_aperture_resource ((u32 )__pa (p), aper_size); -register_nosave_region ((u32 )__pa (p) >>PAGE_SHIFT , - (u32 )__pa (p+aper_size) >>PAGE_SHIFT ); + aper_size >>10 , addr); +insert_aperture_resource ((u32 )addr, aper_size); +register_nosave_region (addr >>PAGE_SHIFT , + (addr+aper_size) >>PAGE_SHIFT ); -return (u32 )__pa (p); +return (u32 )addr; }
[tip:x86/mm] x86-64, gart: Fix allocation with memblock
Commit-ID: 32e3f2b00c529477d26895c5428ed95bba537443 Gitweb: http://git.kernel.org/tip/32e3f2b00c529477d26895c5428ed95bba537443 Author: Yinghai Lu <[email protected]> AuthorDate: Fri, 17 Dec 2010 16:58:40 -0800 Committer: H. Peter Anvin <[email protected]> CommitDate: Wed, 29 Dec 2010 14:46:54 -0800
x86-64, gart: Fix allocation with memblock
When trying to change alloc_bootmem with memblock to go with real top-down Found one old system:
[ 0.000000] Node 0: aperture @ ac000000 size 64 MB [ 0.000000] Aperture pointing to e820 RAM. Ignoring. [ 0.000000] Your BIOS doesn't leave a aperture memory hole [ 0.000000] Please enable the IOMMU option in the BIOS setup [ 0.000000] This costs you 64 MB of RAM [ 0.000000] memblock_x86_reserve_range: [0x2020000000-0x2023ffffff] aperture64 [ 0.000000] Cannot allocate aperture memory hole (ffff882020000000,65536K) [ 0.000000] memblock_x86_free_range: [0x2020000000-0x2023ffffff] [ 0.000000] Kernel panic - not syncing: Not enough memory for aperture [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.37-rc5-tip-yh-06229-gb792dc2-dirty #331 [ 0.000000] Call Trace: [ 0.000000] [<ffffffff81cf50fe>] ? panic+0x91/0x1a3 [ 0.000000] [<ffffffff827c66b2>] ? gart_iommu_hole_init+0x3d7/0x4a3 [ 0.000000] [<ffffffff81d026a9>] ? _etext+0x0/0x3 [ 0.000000] [<ffffffff827ba940>] ? pci_iommu_alloc+0x47/0x71 [ 0.000000] [<ffffffff827c820b>] ? mem_init+0x19/0xec [ 0.000000] [<ffffffff827b3c40>] ? start_kernel+0x20a/0x3e8 [ 0.000000] [<ffffffff827b32cc>] ? x86_64_start_reservations+0x9c/0xa0 [ 0.000000] [<ffffffff827b33e4>] ? x86_64_start_kernel+0x114/0x11b
it means __alloc_bootmem_nopanic() get too high for that aperture.
Use memblock_find_in_range() with limit directly.
Signed-off-by Yinghai Lu <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by H. Peter Anvin <[email protected]>
--- arch/x86/kernel/aperture_64.c | 33 ++++++++++++++++----------------- 1 files changed, 16 insertions(+), 17 deletions(-)
arch/x86/kernel/aperture_64.c +16 -17
@@ -13,7 +13,7 @@#include <linux/kernel.h> #include <linux/types.h> #include <linux/init.h> -#include <linux/bootmem.h> +#include <linux/memblock.h> #include <linux/mmzone.h> #include <linux/pci_ids.h> #include <linux/pci.h>
@@ -69,7 +69,7 @@ static void __init insert_aperture_resource(u32 aper_base, u32 aper_size)static u32 __init allocate_aperture (void ) {u32 aper_size; -void *p; +unsigned long addr;/* aper_size should <= 1G */ if (fallback_aper_order >5 )
@@ -95,27 +95,26 @@ static u32 __init allocate_aperture(void)* so don't use 512M below as gart iommu, leave the space for kernel * code for safe */ - p =__alloc_bootmem_nopanic (aper_size, aper_size,512ULL <<20 ); + addr =memblock_find_in_range (0 ,1ULL <<32 , aper_size,512ULL <<20 ); +if (addr ==MEMBLOCK_ERROR || addr + aper_size >0xffffffff ) { +printk (KERN_ERR +"Cannot allocate aperture memory hole (%lx,%uK)\n" , + addr, aper_size>>10 ); +return 0 ; + } +memblock_x86_reserve_range (addr, addr + aper_size,"aperture64" );/* * Kmemleak should not scan this block as it may not be mapped via the * kernel direct mapping. */ -kmemleak_ignore (p); -if (!p ||__pa (p)+aper_size >0xffffffff ) { -printk (KERN_ERR -"Cannot allocate aperture memory hole (%p,%uK)\n" , - p, aper_size>>10 ); -if (p) -free_bootmem (__pa (p), aper_size); -return 0 ; - } +kmemleak_ignore (phys_to_virt (addr));printk (KERN_INFO "Mapping aperture over %d KB of RAM @ %lx\n" , - aper_size >>10 ,__pa (p)); -insert_aperture_resource ((u32 )__pa (p), aper_size); -register_nosave_region ((u32 )__pa (p) >>PAGE_SHIFT , - (u32 )__pa (p+aper_size) >>PAGE_SHIFT ); + aper_size >>10 , addr); +insert_aperture_resource ((u32 )addr, aper_size); +register_nosave_region (addr >>PAGE_SHIFT , + (addr+aper_size) >>PAGE_SHIFT ); -return (u32 )__pa (p); +return (u32 )addr; }
PATCH 3/3 memblock: Make find_memory_core_early() find from top-down
In reply to a message not in the archiveThat is used for find ram in node or bootmem type.
We should make it top-down so it will be consistent to memblock_find.
Suggested-by Jeremy Fitzhardinge <[email protected]>
Signed-off-by Yinghai Lu <[email protected]>
--- mm/page_alloc.c | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-)
mm/page_alloc.c +33 -1
@@ -3556,6 +3556,34 @@ static int __meminit next_active_region_return -1 ; } +/* +* Basic iterator support. Return the last range of PFNs for a node +* Note: nid == MAX_NUMNODES returns last region regardless of node +*/ +static int __meminit last_active_region_index_in_nid (int nid) +{ +int i; + +for (i = nr_nodemap_entries -1 ; i >=0 ; i--) +if (nid ==MAX_NUMNODES || early_node_map[i].nid == nid) +return i; + +return -1 ; +} + +/* +* Basic iterator support. Return the previous active range of PFNs for a node +* Note: nid == MAX_NUMNODES returns next region regardless of node +*/ +static int __meminit previous_active_region_index_in_nid (int index,int nid) +{ +for (index = index -1 ; index >=0 ; index--) +if (nid ==MAX_NUMNODES || early_node_map[index].nid == nid) +return index; + +return -1 ; +} +#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID /* * Required by SPARSEMEM. Given a PFN, return what node the PFN is on.
@@ -3607,6 +3635,10 @@ bool __meminit early_pfn_in_nid(unsignedfor (i =first_active_region_index_in_nid (nid); i !=-1 ; \ i = next_active_region_index_in_nid(i, nid)) +#define for_each_active_range_index_in_nid_reverse (i, nid) \ + for (i = last_active_region_index_in_nid(nid); i != -1; \ + i = previous_active_region_index_in_nid(i, nid)) +/** * free_bootmem_with_active_regions - Call free_bootmem_node for each active range * @nid: The node to free memory on. If MAX_NUMNODES, all nodes are freed.
@@ -3645,7 +3677,7 @@ u64 __init find_memory_core_early(int niint i;/* Need to go over early_node_map to find out good range for node */ -for_each_active_range_index_in_nid (i, nid) { +for_each_active_range_index_in_nid_reverse (i, nid) {u64 addr;u64 ei_start, ei_last;u64 final_start, final_end;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
[tip:x86/mm] memblock: Make find_memory_core_early() find from top-down
Commit-ID: 1a4a678b12c84db9ae5dce424e0e97f0559bb57c Gitweb: http://git.kernel.org/tip/1a4a678b12c84db9ae5dce424e0e97f0559bb57c Author: Yinghai Lu <[email protected]> AuthorDate: Fri, 17 Dec 2010 16:59:07 -0800 Committer: H. Peter Anvin <[email protected]> CommitDate: Wed, 29 Dec 2010 14:46:55 -0800
memblock: Make find_memory_core_early() find from top-down
That is used for find ram in node or bootmem type.
We should make it top-down so it will be consistent to memblock_find, and to avoid allocating potentially valuable low memory before we actually need it.
Suggested-by Jeremy Fitzhardinge <[email protected]>
Signed-off-by Yinghai Lu <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by H. Peter Anvin <[email protected]>
--- mm/page_alloc.c | 34 +++++++++++++++++++++++++++++++++- 1 files changed, 33 insertions(+), 1 deletions(-)
mm/page_alloc.c +33 -1
@@ -3555,6 +3555,34 @@ static int __meminit next_active_region_index_in_nid(int index, int nid)return -1 ; } +/* +* Basic iterator support. Return the last range of PFNs for a node +* Note: nid == MAX_NUMNODES returns last region regardless of node +*/ +static int __meminit last_active_region_index_in_nid (int nid) +{ +int i; + +for (i = nr_nodemap_entries -1 ; i >=0 ; i--) +if (nid ==MAX_NUMNODES || early_node_map[i].nid == nid) +return i; + +return -1 ; +} + +/* +* Basic iterator support. Return the previous active range of PFNs for a node +* Note: nid == MAX_NUMNODES returns next region regardless of node +*/ +static int __meminit previous_active_region_index_in_nid (int index,int nid) +{ +for (index = index -1 ; index >=0 ; index--) +if (nid ==MAX_NUMNODES || early_node_map[index].nid == nid) +return index; + +return -1 ; +} +#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID /* * Required by SPARSEMEM. Given a PFN, return what node the PFN is on.
@@ -3606,6 +3634,10 @@ bool __meminit early_pfn_in_nid(unsigned long pfn, int node)for (i =first_active_region_index_in_nid (nid); i !=-1 ; \ i = next_active_region_index_in_nid(i, nid)) +#define for_each_active_range_index_in_nid_reverse (i, nid) \ + for (i = last_active_region_index_in_nid(nid); i != -1; \ + i = previous_active_region_index_in_nid(i, nid)) +/** * free_bootmem_with_active_regions - Call free_bootmem_node for each active range * @nid: The node to free memory on. If MAX_NUMNODES, all nodes are freed.
@@ -3644,7 +3676,7 @@ u64 __init find_memory_core_early(int nid, u64 size, u64 align,int i;/* Need to go over early_node_map to find out good range for node */ -for_each_active_range_index_in_nid (i, nid) { +for_each_active_range_index_in_nid_reverse (i, nid) {u64 addr;u64 ei_start, ei_last;u64 final_start, final_end;