1. 03 2月, 2010 1 次提交
  2. 13 12月, 2009 1 次提交
  3. 01 9月, 2009 1 次提交
  4. 29 4月, 2008 2 次提交
  5. 15 4月, 2008 1 次提交
    • D
      [LMB] Add lmb_alloc_nid() · c50f68c8
      David S. Miller 提交于
      A variant of lmb_alloc() that tries to allocate memory on a specified
      NUMA node 'nid' but falls back to normal lmb_alloc() if that fails.
      
      The caller provides a 'nid_range' function pointer which assists the
      allocator.  It is given args 'start', 'end', and pointer to integer
      'this_nid'.
      
      It places at 'this_nid' the NUMA node id that corresponds to 'start',
      and returns the end address within 'start' to 'end' at which memory
      assosciated with 'nid' ends.
      
      This callback allows a platform to use lmb_alloc_nid() in just
      about any context, even ones in which early_pfn_to_nid() might
      not be working yet.
      
      This function will be used by the NUMA setup code on sparc64, and also
      it can be used by powerpc, replacing it's hand crafted
      "careful_allocation()" function in arch/powerpc/mm/numa.c
      
      If x86 ever converts it's NUMA support over to using the LMB helpers,
      it can use this too as it has something entirely similar.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c50f68c8
  6. 14 2月, 2008 2 次提交
  7. 24 1月, 2008 1 次提交
    • K
      [POWERPC] Fix handling of memreserve if the range lands in highmem · f98eeb4e
      Kumar Gala 提交于
      There were several issues if a memreserve range existed and happened
      to be in highmem:
      
      * The bootmem allocator is only aware of lowmem so calling
        reserve_bootmem with a highmem address would cause a BUG_ON
      * All highmem pages were provided to the buddy allocator
      
      Added a lmb_is_reserved() api that we now use to determine if a highem
      page should continue to be PageReserved or provided to the buddy
      allocator.
      
      Also, we incorrectly reported the amount of pages reserved since all
      highmem pages are initally marked reserved and we clear the
      PageReserved flag as we "free" up the highmem pages.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      f98eeb4e
  8. 17 8月, 2007 1 次提交
  9. 22 3月, 2006 1 次提交
  10. 07 2月, 2006 3 次提交
  11. 09 1月, 2006 1 次提交
  12. 06 10月, 2005 1 次提交
    • P
      powerpc: Merge in the ppc64 version of the prom code. · 9b6b563c
      Paul Mackerras 提交于
      This brings in the ppc64 version of prom_init.c, prom.c and btext.c
      and makes them work for ppc32.  This also brings in the new calling
      convention, where the first entry to the kernel (with r5 != 0) goes
      to the prom_init code, which then restarts from the beginning (with
      r5 == 0) after it has done its stuff.
      
      For now this also brings in the ppc32 version of setup.c.  It also
      merges lmb.h.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9b6b563c
  13. 05 9月, 2005 1 次提交
    • B
      [PATCH] SPARSEMEM EXTREME · 802f192e
      Bob Picco 提交于
      A new option for SPARSEMEM is ARCH_SPARSEMEM_EXTREME.  Architecture
      platforms with a very sparse physical address space would likely want to
      select this option.  For those architecture platforms that don't select the
      option, the code generated is equivalent to SPARSEMEM currently in -mm.
      I'll be posting a patch on ia64 ml which uses this new SPARSEMEM feature.
      
      ARCH_SPARSEMEM_EXTREME makes mem_section a one dimensional array of
      pointers to mem_sections.  This two level layout scheme is able to achieve
      smaller memory requirements for SPARSEMEM with the tradeoff of an
      additional shift and load when fetching the memory section.  The current
      SPARSEMEM -mm implementation is a one dimensional array of mem_sections
      which is the default SPARSEMEM configuration.  The patch attempts isolates
      the implementation details of the physical layout of the sparsemem section
      array.
      
      ARCH_SPARSEMEM_EXTREME depends on 64BIT and is by default boolean false.
      
      I've boot tested under aim load ia64 configured for ARCH_SPARSEMEM_EXTREME.
       I've also boot tested a 4 way Opteron machine with !ARCH_SPARSEMEM_EXTREME
      and tested with aim.
      Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: NBob Picco <bob.picco@hp.com>
      Signed-off-by: NDave Hansen <haveblue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      802f192e
  14. 29 8月, 2005 1 次提交
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4