1. 29 Dec, 2010 5 commits
    • Yinghai Lu's avatar
      x86-64, numa: Allocate memnodemap under max_pfn_mapped · dbef7b56
      Yinghai Lu authored
      We need to access it right way, so make sure that it is mapped already.
      
      Prepare to put page table on local node, and nodemap is used before that.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D1933C8.7060105@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      dbef7b56
    • Yinghai Lu's avatar
      x86: Change get_max_mapped() to inline · 45635ab5
      Yinghai Lu authored
      Move it into head file. to prepare use it in other files.
      
      [ hpa: added missing <linux/types.h> and changed type to phys_addr_t. ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D1933BA.8000508@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      45635ab5
    • Yinghai Lu's avatar
      memblock: Make find_memory_core_early() find from top-down · 1a4a678b
      Yinghai Lu authored
      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: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D0C075B.3040501@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      1a4a678b
    • Yinghai Lu's avatar
      x86-64, gart: Fix allocation with memblock · 32e3f2b0
      Yinghai Lu authored
      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: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D0C0740.90104@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      32e3f2b0
    • Yinghai Lu's avatar
      x86-64, mm: Put early page table high · 4b239f45
      Yinghai Lu authored
      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: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D0C0734.7060900@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      4b239f45
  2. 18 Nov, 2010 3 commits
  3. 16 Nov, 2010 1 commit
  4. 15 Nov, 2010 31 commits