1. 27 Apr, 2008 30 commits
  2. 26 Apr, 2008 10 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of... · c3bf9bc2
      Linus Torvalds authored
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-bigbox-bootmem-v3
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-bigbox-bootmem-v3:
        x86_64/mm: check and print vmemmap allocation continuous
        x86_64: fix setup_node_bootmem to support big mem excluding with memmap
        x86_64: make reserve_bootmem_generic() use new reserve_bootmem()
        mm: allow reserve_bootmem() cross nodes
        mm: offset align in alloc_bootmem()
        mm: fix alloc_bootmem_core to use fast searching for all nodes
        mm: make mem_map allocation continuous
      c3bf9bc2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild · e3505dd5
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild:
        kbuild: scripts/Makefile.modpost typo fix
        kbuild: soften MODULE_LICENSE check
      e3505dd5
    • Yinghai Lu's avatar
      x86_64/mm: check and print vmemmap allocation continuous · c2b91e2e
      Yinghai Lu authored
      On big systems with lots of memory, don't print out too much during
      bootup, and make it easy to find if it is continuous.
      
      on 256G 8 sockets system will get
       [ffffe20000000000-ffffe20002bfffff] PMD -> [ffff810001400000-ffff810003ffffff] on node 0
      [ffffe2001c700000-ffffe2001c7fffff] potential offnode page_structs
       [ffffe20002c00000-ffffe2001c7fffff] PMD -> [ffff81000c000000-ffff8100255fffff] on node 0
      [ffffe20038700000-ffffe200387fffff] potential offnode page_structs
       [ffffe2001c800000-ffffe200387fffff] PMD -> [ffff810820200000-ffff81083c1fffff] on node 1
       [ffffe20040000000-ffffe2007fffffff] PUD ->ffff811027a00000 on node 2
       [ffffe20038800000-ffffe2003fffffff] PMD -> [ffff811020200000-ffff8110279fffff] on node 2
      [ffffe20054700000-ffffe200547fffff] potential offnode page_structs
       [ffffe20040000000-ffffe200547fffff] PMD -> [ffff811027c00000-ffff81103c3fffff] on node 2
      [ffffe20070700000-ffffe200707fffff] potential offnode page_structs
       [ffffe20054800000-ffffe200707fffff] PMD -> [ffff811820200000-ffff81183c1fffff] on node 3
       [ffffe20080000000-ffffe200bfffffff] PUD ->ffff81202fa00000 on node 4
       [ffffe20070800000-ffffe2007fffffff] PMD -> [ffff812020200000-ffff81202f9fffff] on node 4
      [ffffe2008c700000-ffffe2008c7fffff] potential offnode page_structs
       [ffffe20080000000-ffffe2008c7fffff] PMD -> [ffff81202fc00000-ffff81203c3fffff] on node 4
      [ffffe200a8700000-ffffe200a87fffff] potential offnode page_structs
       [ffffe2008c800000-ffffe200a87fffff] PMD -> [ffff812820200000-ffff81283c1fffff] on node 5
       [ffffe200c0000000-ffffe200ffffffff] PUD ->ffff813037a00000 on node 6
       [ffffe200a8800000-ffffe200bfffffff] PMD -> [ffff813020200000-ffff8130379fffff] on node 6
      [ffffe200c4700000-ffffe200c47fffff] potential offnode page_structs
       [ffffe200c0000000-ffffe200c47fffff] PMD -> [ffff813037c00000-ffff81303c3fffff] on node 6
       [ffffe200c4800000-ffffe200e07fffff] PMD -> [ffff813820200000-ffff81383c1fffff] on node 7
      
      instead of a very long print out...
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      c2b91e2e
    • Yinghai Lu's avatar
      x86_64: fix setup_node_bootmem to support big mem excluding with memmap · 1a27fc0a
      Yinghai Lu authored
      typical case: four sockets system, every node has 4g ram, and we are using:
      
      	memmap=10g$4g
      
      to mask out memory on node1 and node2
      
      when numa is enabled, early_node_mem is used to get node_data and node_bootmap.
      
      if it can not get memory from the same node with find_e820_area(), it will
      use alloc_bootmem to get buff from previous nodes.
      
      so check it and print out some info about it.
      
      need to move early_res_to_bootmem into every setup_node_bootmem.
      and it takes range that node has. otherwise alloc_bootmem could return addr
      that reserved early.
      
      depends on "mm: make reserve_bootmem can crossed the nodes".
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1a27fc0a
    • Yinghai Lu's avatar
      x86_64: make reserve_bootmem_generic() use new reserve_bootmem() · 8b3cd09e
      Yinghai Lu authored
      "mm: make reserve_bootmem can crossed the nodes" provides new
      reserve_bootmem(), let reserve_bootmem_generic() use that.
      
      reserve_bootmem_generic() is used to reserve initramdisk, so this way
      we can make sure even when bootloader or kexec load ranges cross the
      node memory boundaries, reserve_bootmem still works.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8b3cd09e
    • Yinghai Lu's avatar
      mm: allow reserve_bootmem() cross nodes · a5645a61
      Yinghai Lu authored
      split reserve_bootmem_core() into two functions, one which checks
      conflicts, and one which sets the bits.
      
      and make reserve_bootmem to loop bdata_list to cross the nodes.
      
      user could be crashkernel and ramdisk..., in case the range provided
      by those externalities crosses the nodes.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a5645a61
    • Yinghai Lu's avatar
      mm: offset align in alloc_bootmem() · 9a2dc04c
      Yinghai Lu authored
      need offset alignment when node_boot_start's alignment is less than
      the alignment required.
      
      use local node_boot_start to match alignment - so don't add extra operation
      in search loop.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9a2dc04c
    • Yinghai Lu's avatar
      mm: fix alloc_bootmem_core to use fast searching for all nodes · ad09315c
      Yinghai Lu authored
      Make the nodes other than node 0 use bdata->last_success for fast
      search too.
      
      We need to use __alloc_bootmem_core() for vmemmap allocation for other
      nodes when numa and sparsemem/vmemmap are enabled.
      
      Also, make fail_block path increase i with incr only after ALIGN
      to avoid extra increase when size is larger than align.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ad09315c
    • Yinghai Lu's avatar
      mm: make mem_map allocation continuous · e123dd3f
      Yinghai Lu authored
      vmemmap allocation currently has this layout:
      
       [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
       [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001800000 on node 0
       [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001c00000 on node 0
       [ffffe20000600000-ffffe200007fffff] PMD ->ffff810002000000 on node 0
       [ffffe20000800000-ffffe200009fffff] PMD ->ffff810002400000 on node 0
      ...
      
      note that there is a 2M hole between them - not optimal.
      
      the root cause is that usemap (24 bytes) will be allocated after every 2M
      mem_map, and it will push next vmemmap (2M) to the next (2M) alignment.
      
      solution: try to allocate the mem_map continously.
      
      after the patch, we get:
      
       [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
       [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
       [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001800000 on node 0
       [ffffe20000600000-ffffe200007fffff] PMD ->ffff810001a00000 on node 0
       [ffffe20000800000-ffffe200009fffff] PMD ->ffff810001c00000 on node 0
      ...
      
      which is the ideal layout.
      
      and usemap will share a page because of they are allocated continuously too:
      
      sparse_early_usemap_alloc: usemap = ffff810024e00000 size = 24
      sparse_early_usemap_alloc: usemap = ffff810024e00080 size = 24
      sparse_early_usemap_alloc: usemap = ffff810024e00100 size = 24
      sparse_early_usemap_alloc: usemap = ffff810024e00180 size = 24
      ...
      
      so we make the bootmem allocation more compact and use less memory
      for usemap => mission accomplished ;-)
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e123dd3f
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of... · 9b79ed95
      Linus Torvalds authored
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops-v3
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops-v3:
        x86, bitops: select the generic bitmap search functions
        x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only
        x86: finalize bitops unification
        x86, UML: remove x86-specific implementations of find_first_bit
        x86: optimize find_first_bit for small bitmaps
        x86: switch 64-bit to generic find_first_bit
        x86: generic versions of find_first_(zero_)bit, convert i386
        bitops: use __fls for fls64 on 64-bit archs
        generic: implement __fls on all 64-bit archs
        generic: introduce a generic __fls implementation
        x86: merge the simple bitops and move them to bitops.h
        x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
        x86, uml: fix uml with generic find_next_bit for x86
        x86: change x86 to use generic find_next_bit
        uml: Kconfig cleanup
        uml: fix build error
      9b79ed95