linux-toradex.git/include/linux/memblock.h, branch v3.14.3

mm: free memblock.memory in free_all_bootmem

2014-01-24T00:36:51+00:00

When calling free_all_bootmem() the free areas under memblock's control
are released to the buddy allocator.  Additionally the reserved list is
freed if it was reallocated by memblock.  The same should apply for the
memory list.

Signed-off-by: Philipp Hachtmann 
Reviewed-by: Tejun Heo 
Cc: Joonsoo Kim 
Cc: Johannes Weiner 
Cc: Tang Chen 
Cc: Toshi Kani 
Cc: Jianguo Wu 
Cc: Yinghai Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock: switch to use NUMA_NO_NODE instead of MAX_NUMNODES

2014-01-22T00:19:46+00:00

It's recommended to use NUMA_NO_NODE everywhere to select "process any
node" behavior or to indicate that "no node id specified".

Hence, update __next_free_mem_range*() API's to accept both NUMA_NO_NODE
and MAX_NUMNODES, but emit warning once on MAX_NUMNODES, and correct
corresponding API's documentation to describe new behavior.  Also,
update other memblock/nobootmem APIs where MAX_NUMNODES is used
dirrectly.

The change was suggested by Tejun Heo.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar 
Cc: Yinghai Lu 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Cc: Arnd Bergmann 
Cc: Christoph Lameter 
Cc: Greg Kroah-Hartman 
Cc: H. Peter Anvin 
Cc: Johannes Weiner 
Cc: KAMEZAWA Hiroyuki 
Cc: Konrad Rzeszutek Wilk 
Cc: Michal Hocko 
Cc: Paul Walmsley 
Cc: Pavel Machek 
Cc: Russell King 
Cc: Tony Lindgren 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock: reorder parameters of memblock_find_in_range_node

2014-01-22T00:19:46+00:00

Reorder parameters of memblock_find_in_range_node to be consistent with
other memblock APIs.

The change was suggested by Tejun Heo .

Signed-off-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar 
Cc: Yinghai Lu 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Cc: Arnd Bergmann 
Cc: Christoph Lameter 
Cc: Greg Kroah-Hartman 
Cc: H. Peter Anvin 
Cc: Johannes Weiner 
Cc: KAMEZAWA Hiroyuki 
Cc: Konrad Rzeszutek Wilk 
Cc: Michal Hocko 
Cc: Paul Walmsley 
Cc: Pavel Machek 
Cc: Russell King 
Cc: Tony Lindgren 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock, mem_hotplug: make memblock skip hotpluggable regions if needed

2014-01-22T00:19:45+00:00

Linux kernel cannot migrate pages used by the kernel.  As a result,
hotpluggable memory used by the kernel won't be able to be hot-removed.
To solve this problem, the basic idea is to prevent memblock from
allocating hotpluggable memory for the kernel at early time, and arrange
all hotpluggable memory in ACPI SRAT(System Resource Affinity Table) as
ZONE_MOVABLE when initializing zones.

In the previous patches, we have marked hotpluggable memory regions with
MEMBLOCK_HOTPLUG flag in memblock.memory.

In this patch, we make memblock skip these hotpluggable memory regions
in the default top-down allocation function if movable_node boot option
is specified.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Tang Chen 
Signed-off-by: Zhang Yanfei 
Cc: "H. Peter Anvin" 
Cc: "Rafael J . Wysocki" 
Cc: Chen Tang 
Cc: Gong Chen 
Cc: Ingo Molnar 
Cc: Jiang Liu 
Cc: Johannes Weiner 
Cc: Lai Jiangshan 
Cc: Larry Woodman 
Cc: Len Brown 
Cc: Liu Jiang 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Prarit Bhargava 
Cc: Rik van Riel 
Cc: Taku Izumi 
Cc: Tejun Heo 
Cc: Thomas Gleixner 
Cc: Thomas Renninger 
Cc: Toshi Kani 
Cc: Vasilis Liaskovitis 
Cc: Wanpeng Li 
Cc: Wen Congyang 
Cc: Yasuaki Ishimatsu 
Cc: Yinghai Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: make memblock_set_node() support different memblock_type

2014-01-22T00:19:44+00:00

[sfr@canb.auug.org.au: fix powerpc build]
Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
Cc: "H. Peter Anvin" 
Cc: "Rafael J . Wysocki" 
Cc: Chen Tang 
Cc: Gong Chen 
Cc: Ingo Molnar 
Cc: Jiang Liu 
Cc: Johannes Weiner 
Cc: Lai Jiangshan 
Cc: Larry Woodman 
Cc: Len Brown 
Cc: Liu Jiang 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Prarit Bhargava 
Cc: Rik van Riel 
Cc: Taku Izumi 
Cc: Tejun Heo 
Cc: Thomas Gleixner 
Cc: Thomas Renninger 
Cc: Toshi Kani 
Cc: Vasilis Liaskovitis 
Cc: Wanpeng Li 
Cc: Wen Congyang 
Cc: Yasuaki Ishimatsu 
Cc: Yinghai Lu 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock, mem_hotplug: introduce MEMBLOCK_HOTPLUG flag to mark hotpluggable regions

2014-01-22T00:19:44+00:00

In find_hotpluggable_memory, once we find out a memory region which is
hotpluggable, we want to mark them in memblock.memory.  So that we could
control memblock allocator not to allocte hotpluggable memory for the
kernel later.

To achieve this goal, we introduce MEMBLOCK_HOTPLUG flag to indicate the
hotpluggable memory regions in memblock and a function
memblock_mark_hotplug() to mark hotpluggable memory if we find one.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
Cc: "H. Peter Anvin" 
Cc: "Rafael J . Wysocki" 
Cc: Chen Tang 
Cc: Gong Chen 
Cc: Ingo Molnar 
Cc: Jiang Liu 
Cc: Johannes Weiner 
Cc: Lai Jiangshan 
Cc: Larry Woodman 
Cc: Len Brown 
Cc: Liu Jiang 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Prarit Bhargava 
Cc: Rik van Riel 
Cc: Taku Izumi 
Cc: Tejun Heo 
Cc: Thomas Gleixner 
Cc: Thomas Renninger 
Cc: Toshi Kani 
Cc: Vasilis Liaskovitis 
Cc: Wanpeng Li 
Cc: Wen Congyang 
Cc: Yasuaki Ishimatsu 
Cc: Yinghai Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock, numa: introduce flags field into memblock

2014-01-22T00:19:44+00:00

There is no flag in memblock to describe what type the memory is.
Sometimes, we may use memblock to reserve some memory for special usage.
And we want to know what kind of memory it is.  So we need a way to

In hotplug environment, we want to reserve hotpluggable memory so the
kernel won't be able to use it.  And when the system is up, we have to
free these hotpluggable memory to buddy.  So we need to mark these
memory first.

In order to do so, we need to mark out these special memory in memblock.
In this patch, we introduce a new "flags" member into memblock_region:

   struct memblock_region {
           phys_addr_t base;
           phys_addr_t size;
           unsigned long flags;		/* This is new. */
   #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
           int nid;
   #endif
   };

This patch does the following things:
1) Add "flags" member to memblock_region.
2) Modify the following APIs' prototype:
	memblock_add_region()
	memblock_insert_region()
3) Add memblock_reserve_region() to support reserve memory with flags, and keep
   memblock_reserve()'s prototype unmodified.
4) Modify other APIs to support flags, but keep their prototype unmodified.

The idea is from Wen Congyang  and Liu Jiang .

Suggested-by: Wen Congyang 
Suggested-by: Liu Jiang 
Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
Cc: "H. Peter Anvin" 
Cc: "Rafael J . Wysocki" 
Cc: Chen Tang 
Cc: Gong Chen 
Cc: Ingo Molnar 
Cc: Jiang Liu 
Cc: Johannes Weiner 
Cc: Lai Jiangshan 
Cc: Larry Woodman 
Cc: Len Brown 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Prarit Bhargava 
Cc: Rik van Riel 
Cc: Taku Izumi 
Cc: Tejun Heo 
Cc: Thomas Gleixner 
Cc: Thomas Renninger 
Cc: Toshi Kani 
Cc: Vasilis Liaskovitis 
Cc: Wanpeng Li 
Cc: Yasuaki Ishimatsu 
Cc: Yinghai Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock.c: introduce bottom-up allocation mode

2013-11-13T03:09:08+00:00

The Linux kernel cannot migrate pages used by the kernel.  As a result,
kernel pages cannot be hot-removed.  So we cannot allocate hotpluggable
memory for the kernel.

ACPI SRAT (System Resource Affinity Table) contains the memory hotplug
info.  But before SRAT is parsed, memblock has already started to allocate
memory for the kernel.  So we need to prevent memblock from doing this.

In a memory hotplug system, any numa node the kernel resides in should be
unhotpluggable.  And for a modern server, each node could have at least
16GB memory.  So memory around the kernel image is highly likely
unhotpluggable.

So the basic idea is: Allocate memory from the end of the kernel image and
to the higher memory.  Since memory allocation before SRAT is parsed won't
be too much, it could highly likely be in the same node with kernel image.

The current memblock can only allocate memory top-down.  So this patch
introduces a new bottom-up allocation mode to allocate memory bottom-up.
And later when we use this allocation direction to allocate memory, we
will limit the start address above the kernel.

Signed-off-by: Tang Chen 
Signed-off-by: Zhang Yanfei 
Acked-by: Toshi Kani 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Tejun Heo 
Cc: Wanpeng Li 
Cc: Thomas Renninger 
Cc: Yinghai Lu 
Cc: Jiang Liu 
Cc: Wen Congyang 
Cc: Lai Jiangshan 
Cc: Yasuaki Ishimatsu 
Cc: Taku Izumi 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Kamezawa Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock, numa: binary search node id

2013-09-11T22:57:51+00:00

Current early_pfn_to_nid() on arch that support memblock go over
memblock.memory one by one, so will take too many try near the end.

We can use existing memblock_search to find the node id for given pfn,
that could save some time on bigger system that have many entries
memblock.memory array.

Here are the timing differences for several machines.  In each case with
the patch less time was spent in __early_pfn_to_nid().

                        3.11-rc5        with patch      difference (%)
                        --------        ----------      --------------
UV1: 256 nodes  9TB:     411.66          402.47         -9.19 (2.23%)
UV2: 255 nodes 16TB:    1141.02         1138.12         -2.90 (0.25%)
UV2:  64 nodes  2TB:     128.15          126.53         -1.62 (1.26%)
UV2:  32 nodes  2TB:     121.87          121.07         -0.80 (0.66%)
                        Time in seconds.

Signed-off-by: Yinghai Lu 
Cc: Tejun Heo 
Acked-by: Russ Anderson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, ACPI, mm: Revert movablemem_map support

2013-03-02T17:34:39+00:00

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:
    set_cpu_sibling_map+0x279/0x449
    start_secondary+0x11d/0x1e5

Don Morris reproduced on a HP z620 workstation, and bisected it to
commit e8d195525809 ("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
	nodes_clear(numa_nodes_parsed)
	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
	anymore.
  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
node.

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:

 f7210e6c4ac7 ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
    protect movablecore_map in memblock_overlaps_region().")

 01a178a94e8e ("acpi, memory-hotplug: support getting hotplug info from
    SRAT")

 27168d38fa20 ("acpi, memory-hotplug: extend movablemem_map ranges to
    the end of node")

 e8d195525809 ("acpi, memory-hotplug: parse SRAT before memblock is
    ready")

 fb06bc8e5f42 ("page_alloc: bootmem limit with movablecore_map")

 42f47e27e761 ("page_alloc: make movablemem_map have higher priority")

 6981ec31146c ("page_alloc: introduce zone_movable_limit[] to keep
    movable limit for nodes")

 34b71f1e04fc ("page_alloc: add movable_memmap kernel parameter")

 4d59a75125d5 ("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: Tim Gardner 
Reported-by: Don Morris 
Bisected-by: Don Morris 
Tested-by: Don Morris 
Signed-off-by: Yinghai Lu 
Cc: Tony Luck 
Cc: Thomas Renninger 
Cc: Tejun Heo 
Cc: Tang Chen 
Cc: Yasuaki Ishimatsu 
Signed-off-by: Linus Torvalds