From patchwork Thu Oct 22 12:58:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oscar Salvador X-Patchwork-Id: 11851191 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9DE516A2 for ; Thu, 22 Oct 2020 12:58:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38D382417D for ; Thu, 22 Oct 2020 12:58:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38D382417D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 716EC6B005D; Thu, 22 Oct 2020 08:58:44 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 69F5C6B0062; Thu, 22 Oct 2020 08:58:44 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53FF36B0068; Thu, 22 Oct 2020 08:58:44 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 1FC516B005D for ; Thu, 22 Oct 2020 08:58:44 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B9EE1181AC9BF for ; Thu, 22 Oct 2020 12:58:43 +0000 (UTC) X-FDA: 77399565726.26.silk31_3f15d8327251 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 88AC11804B661 for ; Thu, 22 Oct 2020 12:58:43 +0000 (UTC) X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,osalvador@suse.de,,RULES_HIT:30045:30051:30054:30062:30070:30074:30075,0,RBL:195.135.220.15:@suse.de:.lbl8.mailshell.net-64.100.201.201 62.2.6.2;04y8w5sifzfc7fozxksnbzjn16uxgoc1fg9xbxfr9mqdwn6s4c1jgmwunyi87tk.iqbz75wyq97tprpayf3eoopmzqwu43wxn4rm5bf6de5h6cx3x67qcc3rdp9krda.k-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: silk31_3f15d8327251 X-Filterd-Recvd-Size: 7078 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 12:58:42 +0000 (UTC) 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 E49D9ACD0; Thu, 22 Oct 2020 12:58:41 +0000 (UTC) From: Oscar Salvador To: david@redhat.com Cc: mhocko@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz, pasha.tatashin@soleen.com, Oscar Salvador Subject: [RFC PATCH 0/3] Allocate memmap from hotadded memory (per device) Date: Thu, 22 Oct 2020 14:58:32 +0200 Message-Id: <20201022125835.26396-1-osalvador@suse.de> X-Mailer: git-send-email 2.13.7 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This patchset would be the next version of [1], but a lot has changed in the meantime, so I figured I would just make another RFC. After some discussions with David off the list, we agreed that it would be easier as a starter to only support memmap from hotadded memory if the hotadded range spans a single memory device. The reason behind is that at any given time, a memory_block is either online or offline, and so the pages within it. That means that operations like pfn_to_online_page always returns always the right thing. But that would not be the case if we support spanning multiple devices with the infrastructure we have at the moment. We have two options to support spanning multiple memory devices (which is the final goal of this work): 1) We play with sub-section bitmap, so although a section might be offline a pfn_to_online_page made on a vmemmap page will give us the right value. I was tempted to explore this, I am leaning more towards #2. 2) Do some work towards flexible-sized memory devices. The way I see it, a memory_block device would be as big as the hot-added range so we could have memory_blocks of 1GB, 512MB, 64GB, all depending on the size of the device to be added to the system. I am addind some David's notes in here: " Case 1: add_memory() spans a single memory device The memory can be either online/offline, and thereby, all sections online/offline. Nobody should be touching the vmemmap (even during add_memory() - except when poisoning vmemmap, which should most probably work as well, if not we can work around that). Case 2: add_memory() spans multiple memory devices Option 1: As we discussed, only cover full sections with the vmemmap. "Bad" thing is that the memory devices holding the vemmap might be offline to user space, but still contain relevant data ... bad for kexec-tools when creating memory to dump via kdump. Won't properly work. Option 2: Later extend option 1 to use sub-section online bitmap. Option 3: Convert to case 1. Michal proposed allowing flexible-sized memory devices. Will require some work, but would be the cleanest IMHO. So maybe starting with case 1 is best for now, and later extending it via Case2.3 - which would simply be reworking memory devices." " " 1. It can happen that pfn_online() for a vmemmap page returns either true or false, depending on the state of the section. It could be that the memory block holding the vmemmap is offline while another memory block making use of it is online. I guess this isn't bad (I assume it is similar for the altmap), however it could be that makedumpfile will exclude the vmemmap from dumps (as it will usually only dump pages in sections marked online if I am not wrong - maybe it special cases vmemmaps already). Also, could be that it is not saved/restored during hibernation. We'll have to verify." This does not go without saying that the patchset is not 100% complete. It is missing: - a way to disable memmap_on_memory (either sysfs or boot_time cmd) - atm, arch_add_memory for s390 screams if an altmap is passed. I am still thinking of a way to nicely drop handle that. Maybe a function in s390 that sets memmap_on_memory false and stuff that check in support_memmap_on_memory function. 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. Oscar Salvador (3): mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY mm: Introduce a new Vmemmap page-type mm,memory_hotplug: Allocate memmap from the added memory range drivers/acpi/acpi_memhotplug.c | 2 +- drivers/base/memory.c | 21 +++-- include/linux/memory.h | 3 +- include/linux/memory_hotplug.h | 27 ++++++- include/linux/memremap.h | 2 +- include/linux/mm.h | 6 ++ include/linux/mm_types.h | 5 ++ include/linux/page-flags.h | 6 ++ mm/memory_hotplug.c | 139 +++++++++++++++++++++++++++------ mm/memremap.c | 5 +- mm/page_alloc.c | 7 ++ mm/sparse.c | 25 ++++++ 12 files changed, 205 insertions(+), 43 deletions(-)