1. 17 Apr, 2013 3 commits
  2. 07 Mar, 2013 1 commit
  3. 02 Mar, 2013 1 commit
    • Yinghai Lu's avatar
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu authored
      Tim found:
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      It turns out movable_map has some problems, and it breaks several things
      1. numa_init is called several times, NOT just for srat. so those
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      So just remove that offending commit and related ones including:
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
       4d59a751 ("x86: get pg_data_t's memory from other node")
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Reported-by: default avatarDon Morris <don.morris@hp.com>
      Bisected-by: default avatarDon Morris <don.morris@hp.com>
      Tested-by: default avatarDon Morris <don.morris@hp.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 24 Feb, 2013 1 commit
    • Tang Chen's avatar
      acpi, memory-hotplug: parse SRAT before memblock is ready · e8d19552
      Tang Chen authored
      On linux, the pages used by kernel could not be migrated.  As a result,
      if a memory range is used by kernel, it cannot be hot-removed.  So if we
      want to hot-remove memory, we should prevent kernel from using it.
      The way now used to prevent this is specify a memory range by
      movablemem_map boot option and set it as ZONE_MOVABLE.
      But when the system is booting, memblock will allocate memory, and
      reserve the memory for kernel.  And before we parse SRAT, and know the
      node memory ranges, memblock is working.  And it may allocate memory in
      ranges to be set as ZONE_MOVABLE.  This memory can be used by kernel,
      and never be freed.
      So, let's parse SRAT before memblock is called first.  And it is early
      The first call of memblock_find_in_range_node() is in:
      so, this patch add a function early_parse_srat() to parse SRAT, and call
      it before setup_real_mode() is called.
      1) early_parse_srat() is called before numa_init(), and has initialized
         numa_meminfo.  So DO NOT clear numa_nodes_parsed in numa_init() and DO
         NOT zero numa_meminfo in numa_init(), otherwise we will lose memory
         numa info.
      2) I don't know why using count of memory affinities parsed from SRAT
         as a return value in original acpi_numa_init().  So I add a static
         variable srat_mem_cnt to remember this count and use it as the return
         value of the new acpi_numa_init()
      [mhocko@suse.cz: parse SRAT before memblock is ready fix]
      Signed-off-by: default avatarTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: default avatarWen Congyang <wency@cn.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Wu Jianguo <wujianguo@huawei.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Brown, Len" <len.brown@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 14 Feb, 2013 2 commits
  6. 30 Jan, 2013 7 commits
  7. 29 Jan, 2013 6 commits
  8. 14 Jan, 2013 2 commits
  9. 11 Jan, 2013 1 commit
    • Jesse Barnes's avatar
      x86/Sandy Bridge: reserve pages when integrated graphics is present · a9acc536
      Jesse Barnes authored
      SNB graphics devices have a bug that prevent them from accessing certain
      memory ranges, namely anything below 1M and in the pages listed in the
      table.  So reserve those at boot if set detect a SNB gfx device on the
      CPU to avoid GPU hangs.
      Stephane Marchesin had a similar patch to the page allocator awhile
      back, but rather than reserving pages up front, it leaked them at
      allocation time.
      [ hpa: made a number of stylistic changes, marked arrays as static
        const, and made less verbose; use "memblock=debug" for full
        verbosity. ]
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  10. 05 Dec, 2012 1 commit
  11. 17 Nov, 2012 12 commits
  12. 25 Oct, 2012 1 commit
  13. 24 Oct, 2012 1 commit
  14. 17 Oct, 2012 1 commit