[lkml]   [2020]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC PATCH v3 0/4] Allocate memmap from hotadded memory (per device)
This is v3 of [1]:

Changes from v2 -> v3:
- Re-order patches (Michal)
- Fold "mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY" in patch#1
- Add kernel boot option to enable this feature (Michal)

Changes from v1 -> v2:
- Addressed feedback provided by David
- Add a arch_support_memmap_on_memory to be called
from mhp_supports_memmap_on_memory, as atm,
only ARM, powerpc and x86_64 have altmat support.

Original cover letter:


The primary goal of this patchset is to reduce memory overhead of the
hot-added memory (at least for SPARSEMEM_VMEMMAP memory model).
The current way we use to populate memmap (struct page array) has two main drawbacks:

a) it consumes an additional memory until the hotadded memory itself is
onlined and
b) memmap might end up on a different numa node which is especially true
for movable_node configuration.
c) due to fragmentation we might end up populating memmap with base

One way to mitigate all these issues is to simply allocate memmap array
(which is the largest memory footprint of the physical memory hotplug)
from the hot-added memory itself. SPARSEMEM_VMEMMAP memory model allows
us to map any pfn range so the memory doesn't need to be online to be
usable for the array. See patch 3 for more details.
This feature is only usable when CONFIG_SPARSEMEM_VMEMMAP is set.

[Overall design]:

Implementation wise we reuse vmem_altmap infrastructure to override
the default allocator used by vmemap_populate.
memory_block structure gained a new field called nr_vmemmap_pages.
This plays well for two reasons:

1) {offline/online}_pages know the difference between start_pfn and
buddy_start_pfn, which is start_pfn + nr_vmemmap_pages.
In this way all isolation/migration operations are
done to within the right range of memory without vmemmap pages.
This allows us for a much cleaner handling.

2) In try_remove_memory, we construct a new vmemap_altmap struct with the
right information based on memory_block->nr_vmemap_pages, so we end up
calling vmem_altmap_free instead of free_pagetable when removing the memory.

Oscar Salvador (4):
mm,memory_hotplug: Add mhp_supports_memmap_on_memory
mm,memory_hotplug: Allocate memmap from the added memory range
mm,memory_hotplug: Enable MHP_MEMMAP_ON_MEMORY when supported
mm,memory_hotplug: Add mhp_memmap_on_memory boot option

arch/arm64/mm/mmu.c | 5 +
arch/powerpc/mm/mem.c | 5 +
.../platforms/pseries/hotplug-memory.c | 5 +-
arch/x86/mm/init_64.c | 5 +
drivers/acpi/acpi_memhotplug.c | 5 +-
drivers/base/memory.c | 21 +--
include/linux/memory.h | 7 +-
include/linux/memory_hotplug.h | 22 ++-
include/linux/memremap.h | 2 +-
mm/memory_hotplug.c | 127 +++++++++++++++---
mm/page_alloc.c | 4 +-
11 files changed, 171 insertions(+), 37 deletions(-)


 \ /
  Last update: 2020-12-01 12:55    [W:0.175 / U:2.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site