1. 02 5月, 2011 13 次提交
    • T
      x86, NUMA: rename srat_64.c to srat.c · 7b2600f8
      Tejun Heo 提交于
      Rename srat_64.c to srat.c.  This is to prepare for unification of
      NUMA init paths between 32 and 64bit.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      7b2600f8
    • T
      x86, NUMA: trivial cleanups · 1201e10a
      Tejun Heo 提交于
      * Kill no longer used struct bootnode.
      
      * Kill dangling declaration of pxm_to_nid() in numa_32.h.
      
      * Make setup_node_bootmem() static.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      1201e10a
    • T
      x86-32, NUMA: use sparse_memory_present_with_active_regions() · 797390d8
      Tejun Heo 提交于
      Instead of calling memory_present() for each region from NUMA init,
      call sparse_memory_present_with_active_regions() from paging_init()
      similarly to x86-64.
      
      For flat and numaq, this results in exactly the same memory_present()
      calls.  For srat, if there are multiple memory chunks for a node,
      after this change, memory_present() will be called separately for each
      chunk instead of being called once to encompass the whole range, which
      doesn't cause any harm and actually is the better behavior.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      797390d8
    • T
      x86-32, NUMA: Make apic->x86_32_numa_cpu_node() optional · 84914ed0
      Tejun Heo 提交于
      NUMAQ is the only meaningful user of this callback and
      setup_local_APIC() the only callsite.  Stop torturing everyone else by
      making the callback optional and removing all the boilerplate
      implementations and assignments.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      84914ed0
    • T
      x86, NUMA: Unify 32/64bit numa_cpu_node() implementation · 6bd26273
      Tejun Heo 提交于
      Currently, the only meaningful user of apic->x86_32_numa_cpu_node() is
      NUMAQ which returns valid mapping only after CPU is initialized during
      SMP bringup; thus, the previous patch to set apicid -> node in
      setup_local_APIC() makes __apicid_to_node[] always contain the correct
      mapping whether custom apic->x86_32_numa_cpu_node() is used or not.
      
      So, there is no reason to keep separate 32bit implementation.  We can
      always consult __apicid_to_node[].  Move 64bit implementation from
      numa_64.c to numa.c and remove 32bit implementation from numa_32.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      6bd26273
    • T
      x86-32, NUMA: Automatically set apicid -> node in setup_local_APIC() · c4b90c11
      Tejun Heo 提交于
      Some x86-32 NUMA implementations (NUMAQ) don't initialize apicid ->
      node mapping using set_apicid_to_node() during NUMA init but implement
      custom apic->x86_32_numa_cpu_node() instead.
      
      This patch automatically initializes the default apic -> node mapping
      table from apic->x86_32_numa_cpu_node() from setup_local_APIC() such
      that the mapping table is in sync with the actual mapping.
      
      As the table isn't used by custom implementations, this doesn't make
      any difference at this point.  This is in preparation of unifying
      numa_cpu_node() between x86-32 and 64.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      c4b90c11
    • T
      x86-64, NUMA: simplify nodedata allocation · acd26d61
      Tejun Heo 提交于
      With top-down memblock allocation, the allocation range limits in
      ealry_node_mem() can be simplified - try node-local first, then any
      node but in any case don't allocate below DMA limit.
      
      Remove early_node_mem() and implement simplified allocation directly
      in setup_node_bootmem().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      acd26d61
    • T
      x86-64, NUMA: trivial cleanups for setup_node_bootmem() · ebe685f2
      Tejun Heo 提交于
      Make the following trivial changes in preparation for further updates.
      
      * nodeid -> nid, nid -> tnid
      * use nd_ prefix for nodedata related variables
      * remove start/end_pfn and use start/end directly
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      ebe685f2
    • T
      x86-64, NUMA: Simplify hotadd memory handling · 9688678a
      Tejun Heo 提交于
      The only special handling NUMA needs to do for hotadd memory is
      determining the node for the hotadd memory given the address of it and
      there's nothing specific to specific config method used.
      
      srat_64.c does somewhat elaborate error checking on
      ACPI_SRAT_MEM_HOT_PLUGGABLE regions, remembers them and implements
      memory_add_physaddr_to_nid() which determines the node for given
      hotadd address.
      
      This is almost completely redundant.  All the information is already
      available to the generic NUMA code which already performs all the
      sanity checking and merging.  All that's necessary is not using
      __initdata from numa_meminfo and providing a function which uses it to
      map address to node.
      
      Drop the specific implementation from srat_64.c and add generic
      memory_add_physaddr_to_nid() in numa_64.c, which is enabled if
      CONFIG_MEMORY_HOTPLUG is set.  Other than dropping the code, srat_64.c
      doesn't need any change as it already calls numa_add_memblk() for hot
      pluggable regions which is enough.
      
      While at it, change CONFIG_MEMORY_HOTPLUG_SPARSE in srat_64.c to
      CONFIG_MEMORY_HOTPLUG, for NUMA on x86-64, the two are always the
      same.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      9688678a
    • T
      Merge branch 'x86/urgent' into x86-mm · ba67cf5c
      Tejun Heo 提交于
      Merge reason: Pick up the following two fix commits.
      
        2be19102: x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo()
        765af22d: x86-32, NUMA: Fix ACPI NUMA init broken by recent x86-64 change
      
      Scheduled NUMA init 32/64bit unification changes depend on these.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      ba67cf5c
    • T
      Merge branch 'x86/numa' into x86-mm · aff36486
      Tejun Heo 提交于
      Merge reason: Pick up x86-32 remap allocator cleanup changes - 14
      commits, 3fe14ab5^..993ba158.
      
        3fe14ab5: x86-32, numa: Fix failure condition check in alloc_remap()
        993ba158: x86-32, numa: Update remap allocator comments
      
      Scheduled NUMA init 32/64bit unification changes depend on them.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      aff36486
    • Y
      x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo() · 2be19102
      Yinghai Lu 提交于
      numa_cleanup_meminfo() trims each memblk between low (0) and
      high (max_pfn) limits and discards empty ones.  However, the
      emptiness detection incorrectly used equality test.  If the
      start of a memblk is higher than max_pfn, it is empty but fails
      the equality test and doesn't get discarded.
      
      The condition triggers when max_pfn is lower than start of a
      NUMA node and results in memory misconfiguration - leading to
      WARN_ON()s and other funnies.  The bug was discovered in devel
      branch where 32bit too uses this code path for NUMA init.  If a
      node is above the addressing limit, max_pfn ends up lower than
      the node triggering this problem.
      
      The failure hasn't been observed on x86-64 but is still possible
      with broken hardware e820/NUMA info.  As the fix is very low
      risk, it would be better to apply it even for 64bit.
      
      Fix it by using >= instead of ==.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      [ Extracted the actual fix from the original patch and rewrote patch description. ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/20110501171204.GO29280@htj.dyndns.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      2be19102
    • B
      x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors · e20a2d20
      Boris Ostrovsky 提交于
      Older AMD K8 processors (Revisions A-E) are affected by erratum
      400 (APIC timer interrupts don't occur in C states greater than
      C1). This, for example, means that X86_FEATURE_ARAT flag should
      not be set for these parts.
      
      This addresses regression introduced by commit
      b87cf80a ("x86, AMD: Set ARAT
      feature on AMD processors") where the system may become
      unresponsive until external interrupt (such as keyboard input)
      occurs. This results, for example, in time not being reported
      correctly, lack of progress on the system and other lockups.
      Reported-by: NJoerg-Volker Peetz <jvpeetz@web.de>
      Tested-by: NJoerg-Volker Peetz <jvpeetz@web.de>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NBoris Ostrovsky <Boris.Ostrovsky@amd.com>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      e20a2d20
  2. 01 5月, 2011 1 次提交
  3. 30 4月, 2011 6 次提交
  4. 29 4月, 2011 20 次提交