• Tang Chen's avatar
    mm/memblock.c: factor out of top-down allocation · 1402899e
    Tang Chen authored
    [Problem]
    
    The current Linux cannot migrate pages used by the kernel because of the
    kernel direct mapping.  In Linux kernel space, va = pa + PAGE_OFFSET.
    When the pa is changed, we cannot simply update the pagetable and keep the
    va unmodified.  So the kernel pages are not migratable.
    
    There are also some other issues will cause the kernel pages not
    migratable.  For example, the physical address may be cached somewhere and
    will be used.  It is not to update all the caches.
    
    When doing memory hotplug in Linux, we first migrate all the pages in one
    memory device somewhere else, and then remove the device.  But if pages
    are used by the kernel, they are not migratable.  As a result, memory used
    by the kernel cannot be hot-removed.
    
    Modifying the kernel direct mapping mechanism is too difficult to do.  And
    it may cause the kernel performance down and unstable.  So we use the
    following way to do memory hotplug.
    
    [What we are doing]
    
    In Linux, memory in one numa node is divided into several zones.  One of
    the zones is ZONE_MOVABLE, which the kernel won't use.
    
    In order to implement memory hotplug in Linux, we are going to arrange all
    hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these
    memory.  To do this, we need ACPI's help.
    
    In ACPI, SRAT(System Resource Affinity Table) contains NUMA info.  The
    memory affinities in SRAT record every memory range in the system, and
    also, flags specifying if the memory range is hotpluggable.  (Please refer
    to ACPI spec 5.0 5.2.16)
    
    With the help of SRAT, we have to do the following two things to achieve our
    goal:
    
    1. When doing memory hot-add, allow the users arranging hotpluggable as
       ZONE_MOVABLE.
       (This has been done by the MOVABLE_NODE functionality in Linux.)
    
    2. when the system is booting, prevent bootmem allocator from allocating
       hotpluggable memory for the kernel before the memory initialization
       finishes.
    
    The problem 2 is the key problem we are going to solve. But before solving it,
    we need some preparation. Please see below.
    
    [Preparation]
    
    Bootloader has to load the kernel image into memory.  And this memory must
    be unhotpluggable.  We cannot prevent this anyway.  So in a memory hotplug
    system, we can assume any node the kernel resides in is not hotpluggable.
    
    Before SRAT is parsed, we don't know which memory ranges are hotpluggable.
     But memblock has already started to work.  In the current kernel,
    memblock allocates the following memory before SRAT is parsed:
    
    setup_arch()
     |->memblock_x86_fill()            /* memblock is ready */
     |......
     |->early_reserve_e820_mpc_new()   /* allocate memory under 1MB */
     |->reserve_real_mode()            /* allocate memory under 1MB */
     |->init_mem_mapping()             /* allocate page tables, about 2MB to map 1GB memory */
     |->dma_contiguous_reserve()       /* specified by user, should be low */
     |->setup_log_buf()                /* specified by user, several mega bytes */
     |->relocate_initrd()              /* could be large, but will be freed after boot, should reorder */
     |->acpi_initrd_override()         /* several mega bytes */
     |->reserve_crashkernel()          /* could be large, should reorder */
     |......
     |->initmem_init()                 /* Parse SRAT */
    
    According to Tejun's advice, before SRAT is parsed, we should try our best
    to allocate memory near the kernel image.  Since the whole node the kernel
    resides in won't be hotpluggable, and for a modern server, a node may have
    at least 16GB memory, allocating several mega bytes memory around the
    kernel image won't cross to hotpluggable memory.
    
    [About this patchset]
    
    So this patchset is the preparation for the problem 2 that we want to
    solve.  It does the following:
    
    1. Make memblock be able to allocate memory bottom up.
       1) Keep all the memblock APIs' prototype unmodified.
       2) When the direction is bottom up, keep the start address greater than the
          end of kernel image.
    
    2. Improve init_mem_mapping() to support allocate page tables in
       bottom up direction.
    
    3. Introduce "movable_node" boot option to enable and disable this
       functionality.
    
    This patch (of 6):
    
    Create a new function __memblock_find_range_top_down to factor out of
    top-down allocation from memblock_find_in_range_node.  This is a
    preparation because we will introduce a new bottom-up allocation mode in
    the following patch.
    Signed-off-by: default avatarTang Chen <tangchen@cn.fujitsu.com>
    Signed-off-by: default avatarZhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Acked-by: default avatarTejun Heo <tj@kernel.org>
    Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Thomas Renninger <trenn@suse.de>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Jiang Liu <jiang.liu@huawei.com>
    Cc: Wen Congyang <wency@cn.fujitsu.com>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Michal Nazarewicz <mina86@mina86.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    1402899e
memblock.c 30.8 KB