Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp384570pxf; Thu, 8 Apr 2021 05:19:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzasgg7UU23oi1u0+pIvfdaHGKNTRw/67+5cfw54CgZU3s69W+ILzHTHWFATcTI7az9j8h X-Received: by 2002:a17:907:9808:: with SMTP id ji8mr10060455ejc.333.1617884366022; Thu, 08 Apr 2021 05:19:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617884366; cv=none; d=google.com; s=arc-20160816; b=DhkY55SWu++J4UDaPX3td6dp0I61nGytxlqpAdhbDm8PHVft6PdVubl/9ITgIDSCLr QgRQZMaan1p0TcgLqorMdoMsksUJxZHbmFFUZgmygi2toRcgMsU8r+dU5SEaWYYaGQqs yJXxNGxuSZrk2LCNWduCjyAnomKlov5/3eCY5Su5fFWTt/q75VKiHjRC6On+PUWv1S3u wjsyiQabcdToQUwHZ1qZKzJ2H6JprKFSpfsG640p3Ok0f4d9WQ5PuLIyv0fV6NVbnbCo 1pmlY8pzqiLNx1L2HCaPn+ewm+6Qwurk9W4FuxmbIT37dU8YPWovCA36SsWFX6xuli63 AkxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ZDE5/PMSu9KpFSmvpuSWedHZ2IKJwA8q83nSBZ1SGwY=; b=NxkRF2drNEkeGfShLoomNwCTAuowhiojpBgxh4tti3BbgymwGqSsypqajQrc/h+f3n CFcbYe2g6W1pAFSR6jf97Ruc9yZcwCnLmNmr2fLBuK02L7T7CRprHc1QSTn2v9/nwX2g EhCsvdd1YEd9R2kKlLOWHCJhJxgTA7+SBbJxGnC74FL0hvP40/kyulP4PcWy/4sE0dX6 Rfltguj6TJ6P3F2f7GMGyjtWbqj51/37rS3iGexSOyfe8QgPWqLJKKEr5zEX6bCZfVxn ARM4eSDhI0zfXc4YGyigulgmTVYo/zHk+olgHR5i0kJn2sLqrQ1BEsBRpUFyGvkHEok1 r+Bg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id co24si23081359edb.599.2021.04.08.05.19.02; Thu, 08 Apr 2021 05:19:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230322AbhDHMSX (ORCPT + 99 others); Thu, 8 Apr 2021 08:18:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:39296 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229741AbhDHMSW (ORCPT ); Thu, 8 Apr 2021 08:18:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DF835AFCC; Thu, 8 Apr 2021 12:18:10 +0000 (UTC) From: Oscar Salvador To: Andrew Morton Cc: David Hildenbrand , Michal Hocko , Anshuman Khandual , Pavel Tatashin , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [PATCH v7 0/8] Allocate memmap from hotadded memory (per device) Date: Thu, 8 Apr 2021 14:17:56 +0200 Message-Id: <20210408121804.10440-1-osalvador@suse.de> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I decided to send another version with the fixups included as it seemed a bit awkward otherwise. It should ease the review. Sorry for the spam. Changes from v6 -> v7: - Fix check from "mm,memory_hotplug: Relax fully spanned sections check" - Add fixup from "mm,memory_hotplug: Allocate memmap from the added memory range" - Add Reviewed-by from David for patch#2 - Fix changelog in "mm,memory_hotplug: Factor out adjusting present pages into adjust_present_page_count()" Changes from v5 -> v6: - Create memory_block_{online,offline} functions - Create vmemmap_* functions to deal with vmemmap stuff, so {online,offline}_pages remain untouched - Add adjust_present_page_count's patch from David - Relax check in {offline,online}_pages - Rework changelogs Changes from v4 -> v5: - Addressed feedback from David (patch#1) - Tested on x86_64 with different struct page sizes and on large/small memory blocks - Tested on arm64 with 4K, 64K (with and without THP) and with different struct page sizes NOTE: We might need to make this feature and hugetlb-vmemmap feature [1] mutually exclusive. I raised an issue I see in [2]. Hugetlb-vmemmap feature has been withdrawn for the time being due to the need in further changes wrt. locking/freeing context. I will keep an eye, and when the time comes again I will see how the two features play together and how one another can be disabled when needed. Changes from v3 -> v4: - Addressed feedback from David - Wrap memmap_on_memory module thingy with #ifdef on MHP_MEMMAP_ON_MEMORY - Move "depend on MEMORY_HOTPLUG" to MHP_MEMMAP_ON_MEMORY in generic mm/Kconfig - Collect David's Reviewed-bys Changes from v2 -> v3: - Addressed feedback from David - Squash former patch#4 and and patch#5 into patch#1 - Fix config dependency CONFIR_SPARSE_VMEMMAP vs CONFIG_SPARSE_VMEMMAP_ENABLE - Simplify module parameter functions Changes from v1 -> v2 - Addressed feedback from David - Fence off the feature in case struct page size is not multiple of PMD size or pageblock alignment cannot be guaranted - Tested on x86_64 small and large memory_blocks - Tested on arm64 4KB and 64KB page sizes (for some reason I cannot boot my VM with 16KB page size). Arm64 with 4KB page size behaves like x86_64 after [1], which made section size smaller. With 64KB, the feature gets fenced off due to pageblock alignment. Changes from RFCv3 -> v1: - Addressed feedback from David - Re-order patches Changes from v2 -> v3 (RFC): - 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 (RFC): - 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. [1] https://lore.kernel.org/lkml/cover.1611206601.git.sudaraja@codeaurora.org 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 4 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 gains a new field called nr_vmemmap_pages, which accounts for the number of vmemmap pages used by that memory_block. E.g: On x86_64, that is 512 vmemmap pages on small memory bloks and 4096 on large memory blocks (1GB) We also introduce new two functions: memory_block_{online,offline}. These functions take care of initializing/unitializing vmemmap pages prior to calling {online,offline}_pages, so the latter functions can remain totally untouched. More details can be found in the respective changelogs. David Hildenbrand (1): mm,memory_hotplug: Factor out adjusting present pages into adjust_present_page_count() Oscar Salvador (7): drivers/base/memory: Introduce memory_block_{online,offline} mm,memory_hotplug: Relax fully spanned sections check mm,memory_hotplug: Allocate memmap from the added memory range acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE arm64/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE Documentation/admin-guide/kernel-parameters.txt | 17 ++ arch/arm64/Kconfig | 3 + arch/x86/Kconfig | 3 + drivers/acpi/acpi_memhotplug.c | 5 +- drivers/base/memory.c | 93 +++++++++-- include/linux/memory.h | 8 +- include/linux/memory_hotplug.h | 13 ++ include/linux/memremap.h | 2 +- include/linux/mmzone.h | 7 +- mm/Kconfig | 5 + mm/Makefile | 5 +- mm/memory_hotplug.c | 210 ++++++++++++++++++++++-- mm/sparse.c | 2 - 13 files changed, 331 insertions(+), 42 deletions(-) -- 2.16.3