1. 30 Sep, 2005 2 commits
    • Ravikiran G Thirumalai's avatar
      [PATCH] x86_64 early numa init fix · 85cc5135
      Ravikiran G Thirumalai authored
      
      
      The tests Alok carried out on Petr's box confirmed that cpu_to_node[BP] is
      not setup early enough by numa_init_array due to the x86_64 changes in
      2.6.14-rc*, and unfortunately set wrongly by the work around code in
      numa_init_array().  cpu_to_node[0] gets set with 1 early and later gets set
      properly to 0 during identify_cpu() when all cpus are brought up, but
      confusing the numa slab in the process.
      
      Here is a quick fix for this.  The right fix obviously is to have
      cpu_to_node[bsp] setup early for numa_init_array().  The following patch
      will fix the problem now, and the code can stay on even when
      cpu_to_node{BP] gets fixed early correctly.
      
      Thanks to Petr for access to his box.
      
      Signed off by: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: default avatarAlok N Kataria <alokk@calsoftinc.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      85cc5135
    • Ravikiran G Thirumalai's avatar
      [PATCH] x86_64: fix the BP node_to_cpumask · e6a045a5
      Ravikiran G Thirumalai authored
      
      
      Fix the BP node_to_cpumask.  2.6.14-rc* broke the boot cpu bit as the
      cpu_to_node(0) is now not setup early enough for numa_init_array.
      cpu_to_node[] is setup much later at srat_detect_node on acpi srat based
      em64t machines.  This seems like a problem on amd machines too, Tested on
      em64t though.  /sys/devices/system/node/node0/cpumap shows up sanely after
      this patch.
      
      Signed off by: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: default avatarShai Fultheim <shai@scalex86.org>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e6a045a5
  2. 12 Sep, 2005 2 commits
  3. 07 Sep, 2005 1 commit
  4. 27 Aug, 2005 1 commit
    • Andi Kleen's avatar
      [PATCH] x86_64: Tell VM about holes in nodes · 485761bd
      Andi Kleen authored
      
      
      Some nodes can have large holes on x86-64.
      
      This fixes problems with the VM allowing too many dirty pages because it
      overestimates the number of available RAM in a node.  In extreme cases you
      can end up with all RAM filled with dirty pages which can lead to deadlocks
      and other nasty behaviour.
      
      This patch just tells the VM about the known holes from e820.  Reserved
      (like the kernel text or mem_map) is still not taken into account, but that
      should be only a few percent error now.
      
      Small detail is that the flat setup uses the NUMA free_area_init_node() now
      too because it offers more flexibility.
      
      (akpm: lotsa thanks to Martin for working this problem out)
      
      Cc: Martin Bligh <mbligh@mbligh.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      485761bd
  5. 29 Jul, 2005 1 commit
  6. 25 Jun, 2005 1 commit
  7. 23 Jun, 2005 1 commit
  8. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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