linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v2 0/4] Allocate memmap from hotadded memory (per device)
@ 2020-11-25 11:20 Oscar Salvador
  2020-11-25 11:20 ` [RFC PATCH v2 1/4] mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY Oscar Salvador
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Oscar Salvador @ 2020-11-25 11:20 UTC (permalink / raw)
  To: david
  Cc: mhocko, linux-kernel, linux-mm, vbabka, pasha.tatashin, Oscar Salvador

This is v2 of [1]:

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
   pages

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. Once the memmap is
allocated we need a way to mark altmap pfns used for the allocation.
If MHP_MEMMAP_ON_MEMORY flag was passed, we set up the layout of the
altmap structure in add_memory_resource), and then we call
mark_vmemmap_pages() to mark vmemmap pages.

memory_block gained a new field called nr_vmemmap_pages.
This plays well for two reasons:

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

 2) In try_remove_memory, we construct a new vmemap_altmap struct with the
    right info, so we end up calling vmem_altmap_free instead of free_pagetable
    when removing the memory.

[1] https://patchwork.kernel.org/project/linux-mm/cover/20201022125835.26396-1-osalvador@suse.de/

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

 arch/arm64/mm/mmu.c                       |   5 +
 arch/powerpc/mm/mem.c                     |   5 +
 arch/powerpc/platforms/powernv/memtrace.c |   2 +-
 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            |  21 +++-
 include/linux/memremap.h                  |   2 +-
 mm/memory_hotplug.c                       | 119 ++++++++++++++++++----
 mm/page_alloc.c                           |   4 +-
 11 files changed, 158 insertions(+), 38 deletions(-)

-- 
2.26.2



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-11-30  9:12 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-25 11:20 [RFC PATCH v2 0/4] Allocate memmap from hotadded memory (per device) Oscar Salvador
2020-11-25 11:20 ` [RFC PATCH v2 1/4] mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY Oscar Salvador
2020-11-27 14:59   ` Michal Hocko
2020-11-25 11:20 ` [RFC PATCH v2 2/4] mm,memory_hotplug: Allocate memmap from the added memory range Oscar Salvador
2020-11-27 15:15   ` Michal Hocko
2020-11-30  9:12     ` Oscar Salvador
2020-11-25 11:20 ` [RFC PATCH v2 3/4] mm,memory_hotplug: Add mhp_supports_memmap_on_memory Oscar Salvador
2020-11-27 15:02   ` Michal Hocko
2020-11-30  8:50     ` Oscar Salvador
2020-11-25 11:20 ` [RFC PATCH v2 4/4] mm,memory_hotplug: Enable MHP_MEMMAP_ON_MEMORY when supported Oscar Salvador
2020-11-27 11:55   ` Oscar Salvador

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).