1. 27 9月, 2006 2 次提交
    • M
      [PATCH] Account for holes that are outside the range of physical memory · 9c7cd687
      Mel Gorman 提交于
      absent_pages_in_range() made the assumption that users of the API would not
      care about holes beyound the end of physical memory.  This was not the
      case.  This patch will account for ranges outside of physical memory as
      holes correctly.
      
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Keith Mannthey" <kmannth@gmail.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9c7cd687
    • M
      [PATCH] Have x86_64 use add_active_range() and free_area_init_nodes · 5cb248ab
      Mel Gorman 提交于
      Size zones and holes in an architecture independent manner for x86_64.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Keith Mannthey" <kmannth@gmail.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cb248ab
  2. 26 9月, 2006 1 次提交
  3. 23 6月, 2006 1 次提交
  4. 31 5月, 2006 1 次提交
    • D
      [PATCH] x86_64: Handle empty node zero · 0d015324
      Daniel Yeisley 提交于
      From: Daniel Yeisley <dan.yeisley@unisys.com>
      
      It is possible to boot a Unisys ES7000 with CPUs from multiple cells, and not
      also include the memory from those cells.  This can create a scenario where
      node 0 has cpus, but no associated memory.  The system will boot fine in a
      configuration where node 0 has memory, but nodes 2 and 3 do not.
      
      [AK: I rechecked the code and generic code seems to indeed handle that already.
      Dan's original patch had a change for mm/slab.c that seems to be already in now.]
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0d015324
  5. 16 5月, 2006 1 次提交
    • A
      [PATCH] x86_64: Fix memory hotadd heuristics · fad7906d
      Andi Kleen 提交于
      This fixes some boot failures on Dell and Unisys systems with memory
      hotadd added.
      
       - Set hotadd_percent to 0 by default.  This means anybody using hotadd
         memory needs to specify the value on the command line.  That's
         because there are lots of Intel boxes which have a bogus hotplug area
         in their SRAT and they would waste a lot of memory before.
       - Fix calculation of how much memory to use when the hotplug area
         exceeds hotadd_percent
       - Fix fallback when the
       - Fix fallback if memory hotadd is not compiled in.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fad7906d
  6. 10 4月, 2006 2 次提交
    • A
      [PATCH] x86_64: Handle empty PXMs that only contain hotplug memory · a8062231
      Andi Kleen 提交于
      The node setup code would try to allocate the node metadata in the node
      itself, but that fails if there is no memory in there.
      
      This can happen with memory hotplug when the hotplug area defines an so
      far empty node.
      
      Now use bootmem to try to allocate the mem_map in other nodes.
      
      And if it fails don't panic, but just ignore the node.
      
      To make this work I added a new __alloc_bootmem_nopanic function that
      does what its name implies.
      
      TBD should try to use nearby nodes here.  Currently we just use any.
      It's hard to do it better because bootmem doesn't have proper fallback
      lists yet.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a8062231
    • A
      [PATCH] x86_64: Reserve SRAT hotadd memory on x86-64 · 68a3a7fe
      Andi Kleen 提交于
      From: Keith Mannthey, Andi Kleen
      
      Implement memory hotadd without sparsemem. The memory in the SRAT
      hotadd area is just preserved instead and can be activated later.
      
      There are a few restrictions:
      - Only one continuous hotadd area allowed per node
      
      The main problem is dealing with the many buggy SRAT tables
      that are out there. The strategy here is to reject anything
      suspicious.
      
      Originally from Keith Mannthey, with several hacks and changes by AK
      and also contributions from Andrew Morton
      
      [ TBD: Problems pointed out by KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>:
      
       1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n.
      
          Rebuilding zonelist is necessary when the system has just memory <
          4G at boot, and hot add memory > 4G.  because x86_64 has DMA32,
          ZONE_NORAML is not included into zonelist at boot time if system
          doesn't have memory >4G at boot.
      
          [AK: should just force the higher zones at boot time when SRAT tells us]
      
       2) zone and node's spanned_pages and present_pages are not incremented.
          They should be.
      
          For example, our server (ia64/Fujitsu PrimeQuest) can equip memory
          from 4G to 1T(maybe 2T in future), and SRAT will *always* say we have
          possible 1T +memory.  (Microsoft requires "write all possible memory
          in SRAT") When we reserve memmap for possible 1T memory, Linux will
          not work well in +minimum 4G configuraion ;)
      
          [AK: needs limiting to 5-10% of max memory]
       ]
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68a3a7fe
  7. 26 3月, 2006 1 次提交
  8. 18 2月, 2006 2 次提交
  9. 05 2月, 2006 2 次提交
  10. 12 1月, 2006 3 次提交
    • A
      [PATCH] x86_64: Reject SRAT tables that don't cover all memory · 8a6fdd3e
      Andi Kleen 提交于
      Broken BIOS on Iwill 8way systems reports these and it causes the bootmem
      allocator to crash. Add a sanity check if all the PXMs in the
      SRAT table cover all memory as reported by e820. If the sanity
      check fails the SRAT is rejected and the code will fall back
      to discover the NUMA topology using the K8 northbridge registers
      when applicable.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8a6fdd3e
    • A
      [PATCH] x86_64: Return -1 for unknown PCI bus affinity · e4e94072
      Andi Kleen 提交于
      When we don't know the node a PCI bus is connected to return -1.
      This matches the generic code.
      
      Noticed by Ravikiran G Thirumalai <kiran@scalex86.org>
      
      Cc: Ravikiran G Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e4e94072
    • A
      [PATCH] x86_64: Validate SLIT table · 1584b89c
      Andi Kleen 提交于
      A lot of Opteron BIOS just pass 10 in all SLIT entries (10 is the
      normalized unit). This is actually worse than the default heuristic
      because it leads to pci_distance not knowing the difference between
      local and remote nodes anymore. This messes up some NUMA
      heuristics in generic code.
      
      In this case it's better to fall back to the default heuristic
      which just does nodea == nodeb ? 10 : 20.
      
      This patch does some basic sanity checking on the SLIT and only accepts
      the SLIT when it passes.
      
      Invariants enforced are:
      - Node to itself shall be 10
      - Any other distance shouldn't be 10
      - Distances smaller than 10 are illegal
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1584b89c
  11. 15 11月, 2005 2 次提交
    • M
      [PATCH] x86_64: Make node boundaries consistent · ffd10a2b
      Magnus Damm 提交于
      The current x86_64 NUMA memory code is inconsequent when it comes to node
      memory ranges. The exact behaviour varies depending on which config option
      that is used.
      
      setup_node_bootmem() has start and end as arguments and these are used to
      calculate the size of the node like this: (end - start). This is all fine
      if end is pointing to the first non-available byte. The problem is that the
      current x86_64 code sometimes treats it as the last present byte and sometimes
      as the first non-available byte. The result is that some configurations might
      lose a page at the end of the range.
      
      This patch tries to fix CONFIG_ACPI_NUMA, CONFIG_K8_NUMA and CONFIG_NUMA_EMU
      so they all treat the end variable as the first non-available byte. This is
      the same way as the single node code.
      
      The patch is boot tested on dual x86_64 hardware with the above configurations,
      but maybe the removed code is needed as some workaround?
      Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ffd10a2b
    • A
      [PATCH] x86_64: Speed up numa_node_id by putting it directly into the PDA · 69d81fcd
      Andi Kleen 提交于
      Not go from the CPU number to an mapping array.
      Mode number is often used now in fast paths.
      
      This also adds a generic numa_node_id to all the topology includes
      
      Suggested by Eric Dumazet
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69d81fcd
  12. 13 9月, 2005 6 次提交
  13. 29 7月, 2005 2 次提交
  14. 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