Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1148529ybz; Thu, 16 Apr 2020 03:56:30 -0700 (PDT) X-Google-Smtp-Source: APiQypKeLhJgQkjeLMA9J2Z1/kjUWghqvKPI9G1Cei5Fvy41f+6kVcnck7GKWX+Zqh/fMeP/eDOc X-Received: by 2002:aa7:d711:: with SMTP id t17mr16327036edq.296.1587034590675; Thu, 16 Apr 2020 03:56:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587034590; cv=none; d=google.com; s=arc-20160816; b=iJqlddGimoyjMwLQZdk9/e4awKj7zkQNrKc3Pj8xxwWAp2KbMDJfX+CJ1/HnV7Si0v 6KB9fFGODHB+OA7i4ZKJCWsBZhL4yu+sa+Ibhg3kk1hLiZs08r+gyT4W8+lUo40f9e2K X0dMhZkwb9rNXZf0kXDfBr6UXUU1B2thX6dTF9X/T62IjJXe7SEbryXkQnm/mL/R3xnb IRlW9DewOZktBvI4Y3hi9WP0kVEOsyqsDuldpmwetBhiMiGpfE53mwop7q7bWhmhyjcu uKZg9T4q32dlS1REKP39dOeRN713gwiwwuTCBfILNAi9RQaelMphjMOz/vQA4LrDUxM4 jCxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=nfpjA4Z9KH1cEGlN2CGAspzLvogXdOWrRg0QkkSUUkM=; b=UYQPeClTqIeSWkwe91e2IZnq5niIqGkte51/eAUtZgpoqiNi0rrALK6T96M9W8E1xF tYBbJuy7UlD2RwSHOpJGqJDNVxR0iZpKX/NDI3KCNyc6kIh/XIO2WjEMQHkB8NnqaQzw 82Vyq72ng6EP64PTwB559UdNnjnl89cbHK/5BVX/RNTyJI7Kg1/sNUbZv6fGuRVnA0QX 7i0CJQ4ykdtvJx1eP/VKFQ5dt9ZBOPLpl+QCjXinPTwlcRCsm6Q+WU4NmfffXEMrB3V0 BQKxSlyYk1jBRZeO9nP7RTHzM3tOfkxVpK3IUYaYfDBcfvEjUY4TQs1SCdaGFaW2Tney AlUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=byFJYkqo; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oz15si4439483ejb.24.2020.04.16.03.56.03; Thu, 16 Apr 2020 03:56:30 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=byFJYkqo; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505676AbgDPKw7 (ORCPT + 99 others); Thu, 16 Apr 2020 06:52:59 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:28836 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2505437AbgDPKuC (ORCPT ); Thu, 16 Apr 2020 06:50:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587034201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nfpjA4Z9KH1cEGlN2CGAspzLvogXdOWrRg0QkkSUUkM=; b=byFJYkqoanIv3EavmLc4aAPFt1A+hqFclzGGREfiMqPRqReY4iU6ucVBOiNC01nndbmfYI 6+nFw70MLeKy30cN7GQa2tLoe62Nmj3aQbKTfZXUv0+JM1W1/exRhuwPo5wS+1D8ISdQg2 aTXhZnQfPRPl3CJAm/XofZukZVWSZcw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-uk7XGjooNvuOMtWoppfoxQ-1; Thu, 16 Apr 2020 06:47:19 -0400 X-MC-Unique: uk7XGjooNvuOMtWoppfoxQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0EC5D8018A2; Thu, 16 Apr 2020 10:47:18 +0000 (UTC) Received: from t480s.redhat.com (ovpn-114-9.ams2.redhat.com [10.36.114.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id CFC641036D03; Thu, 16 Apr 2020 10:47:15 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Michal Hocko , Baoquan He , Oscar Salvador , Pankaj Gupta , Mike Rapoport , Anshuman Khandual Subject: [PATCH RFC 2/2] mm/memory_hotplug: handle memblocks only with CONFIG_ARCH_KEEP_MEMBLOCK Date: Thu, 16 Apr 2020 12:47:07 +0200 Message-Id: <20200416104707.20219-3-david@redhat.com> In-Reply-To: <20200416104707.20219-1-david@redhat.com> References: <20200416104707.20219-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The comment in add_memory_resource() is stale: hotadd_new_pgdat() will no longer call get_pfn_range_for_nid(), as a hotadded pgdat will simply span no pages at all, until memory is moved to the zone/node via move_pfn_range_to_zone() - e.g., when onlining memory blocks. The only archs that care about memblocks for hotplugged memory (either for iterating over all system RAM or testing for memory validity) are arm64, s390x, and powerpc - due to CONFIG_ARCH_KEEP_MEMBLOCK. Without CONFIG_ARCH_KEEP_MEMBLOCK, we can simply stop messing with memblocks. For s390x, it seems to be fairly easy to avoid CONFIG_ARCH_KEEP_MEMBLOCK. arm64 could rework most code (esp., pfn_valid(), valid_phys_addr_range() and kexec_file_load()) to not require memblocks for hotplugged memory. E.g., as hotplugged memory has no holes and can be identified using !early_section(), arm64's variant of pfn_valid() could be reworked fairly easily to not require memblocks for hotadded memory. powerpc might be more involed. Cc: Andrew Morton Cc: Michal Hocko Cc: Baoquan He Cc: Oscar Salvador Cc: Pankaj Gupta Cc: Mike Rapoport Cc: Anshuman Khandual Signed-off-by: David Hildenbrand --- mm/Kconfig | 3 +++ mm/memory_hotplug.c | 13 +++++++------ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/mm/Kconfig b/mm/Kconfig index c1acc34c1c35..a063fd9cdff4 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -136,6 +136,9 @@ config HAVE_FAST_GUP depends on MMU bool =20 +# Don't discard allocated memory used to track "memory" and "reserved" m= emblocks +# after early boot, so it can still be used to test for validity of memo= ry. +# Also, memblocks are updated with memory hot(un)plug. config ARCH_KEEP_MEMBLOCK bool =20 diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 9b15ce465be2..104285ee9ae8 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1020,13 +1020,9 @@ int __ref add_memory_resource(int nid, struct reso= urce *res) =20 mem_hotplug_begin(); =20 - /* - * Add new range to memblock so that when hotadd_new_pgdat() is called - * to allocate new pgdat, get_pfn_range_for_nid() will be able to find - * this new range and calculate total pages correctly. The range will - * be removed at hot-remove time. - */ +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK memblock_add_node(start, size, nid); +#endif =20 ret =3D __try_online_node(nid, false); if (ret < 0) @@ -1075,7 +1071,9 @@ int __ref add_memory_resource(int nid, struct resou= rce *res) /* rollback pgdat allocation and others */ if (new_node) rollback_node_hotadd(nid); +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK memblock_remove(start, size); +#endif mem_hotplug_done(); return ret; } @@ -1751,8 +1749,11 @@ static int __ref try_remove_memory(int nid, u64 st= art, u64 size) mem_hotplug_begin(); =20 arch_remove_memory(nid, start, size, NULL); + +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK memblock_free(start, size); memblock_remove(start, size); +#endif __release_memory_resource(start, size); =20 try_offline_node(nid); --=20 2.25.1