From patchwork Fri Dec 15 05:25:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Verma, Vishal L" X-Patchwork-Id: 13494000 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78402C4332F for ; Fri, 15 Dec 2023 05:25:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA1748D0115; Fri, 15 Dec 2023 00:25:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4E478D0103; Fri, 15 Dec 2023 00:25:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEEAC8D0115; Fri, 15 Dec 2023 00:25:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BD28B8D0103 for ; Fri, 15 Dec 2023 00:25:44 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 97463A0C20 for ; Fri, 15 Dec 2023 05:25:44 +0000 (UTC) X-FDA: 81567915408.13.DF44F5D Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by imf28.hostedemail.com (Postfix) with ESMTP id 674C7C0009 for ; Fri, 15 Dec 2023 05:25:42 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HC+RvvLo; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of vishal.l.verma@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=vishal.l.verma@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702617942; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ICpmLRSWxW4h+Ok4MRUPEjX88+GqQOKKr/nSwj8Jvt8=; b=mredXxpw8UW4AJoCRR01dLKmk1rJRhapox6+bB5YTmWrslZ50pvSFPlzFG946+Y9O9o89F R/O34ViWF0/A2oV/7QyQNHREJ8uRjyvIf9JbnvRb/QKnD8hgk7yeNU75m5CIP8iwW71Y+G AcREbllEhst6lzR2urp8fY3JMhxP4Ug= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HC+RvvLo; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of vishal.l.verma@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=vishal.l.verma@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702617942; a=rsa-sha256; cv=none; b=vYi/phWZWeqqa0SC6foMMaSCSGM32vS7Nx9S0+CjgAVrQkI2aNBz+kCqEyEHSs6/z1eUyr B35G1neZE8mCe8t4JnLKPno70FMp2pn9GUby6WQ1rqxqklP5djtt0zDfMOf4CHjUhvTnoe /HQjHFVThkGAgV/4EHTPN9annx43lDk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702617942; x=1734153942; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=sNbGEdgrAJp/XDJyFdtJon3rtI5vNIQSMJsEoh64H1k=; b=HC+RvvLoupajt1PW5TfUC8wkv368KE09WgrsqSO9taS+YXfVy16DnjVk OaIoTEF0m38iQykZltxRBh0k7WtXWEupM/HVl7ExIvqaHiH1TGgJ+IGhj hALauW8hCQuN5phQcIH3B2i8fO7Dp9BqvAnl8DzLWEuP68+6K+a5qAfEn GoVfAZEyd05aXYL963eoXaxsYZt3L5an4uQnNDpXMPNOXwYlmOV9f+SLV JafpY9y9S89BY+tyljOg1wchyly9tSafbMjvZ0yW75+ulrqbCamKDu1Xy WUA7tY5m3MIuw21r7CQzwu6EW2DacpW61dXYnwD0L6ls3K6l6fP3tthlL A==; X-IronPort-AV: E=McAfee;i="6600,9927,10924"; a="461695036" X-IronPort-AV: E=Sophos;i="6.04,277,1695711600"; d="scan'208";a="461695036" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2023 21:25:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10924"; a="808847946" X-IronPort-AV: E=Sophos;i="6.04,277,1695711600"; d="scan'208";a="808847946" Received: from mmtakalk-mobl.amr.corp.intel.com (HELO [192.168.1.200]) ([10.212.109.101]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2023 21:25:39 -0800 From: Vishal Verma Date: Thu, 14 Dec 2023 22:25:28 -0700 Subject: [PATCH v6 3/4] mm/memory_hotplug: export mhp_supports_memmap_on_memory() MIME-Version: 1.0 Message-Id: <20231214-vv-dax_abi-v6-3-ad900d698438@intel.com> References: <20231214-vv-dax_abi-v6-0-ad900d698438@intel.com> In-Reply-To: <20231214-vv-dax_abi-v6-0-ad900d698438@intel.com> To: Dan Williams , Vishal Verma , Dave Jiang , Andrew Morton , Oscar Salvador Cc: linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, David Hildenbrand , Dave Hansen , Huang Ying , Greg Kroah-Hartman , linux-mm@kvack.org, Michal Hocko X-Mailer: b4 0.13-dev-433a8 X-Developer-Signature: v=1; a=openpgp-sha256; l=4673; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=sNbGEdgrAJp/XDJyFdtJon3rtI5vNIQSMJsEoh64H1k=; b=owGbwMvMwCXGf25diOft7jLG02pJDKnVj/270n4d1C7Pn6OllvEj6eOC3R8OBFpMDgs02furb V3h077XHaUsDGJcDLJiiix/93xkPCa3PZ8nMMERZg4rE8gQBi5OAZjIaUVGhqvHbgn7n1PPSKt8 aNv1aHOVz+W7sd8qQ4V6SpzvsupvfMzwV6rjV/PTnz9mp3x8tmXRRvvOFYsvNPeVZ3jKPWjX1Zr qzQgA X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF X-Rspamd-Queue-Id: 674C7C0009 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: sdwirps1hd158j31mbn5chg8am5ws767 X-HE-Tag: 1702617942-27128 X-HE-Meta: U2FsdGVkX19oM2rdXLmNUeZ+zSjnOl0Qu+i7zMB3ffZ3S9dXzdnzcAC6qLDPfh/ZqaD9J+UfCgY4MUS1QXLzWJ/A0etwma3T9U8JKEnfFpppXJ0X3fkCdAe/MAEGmhVVzeETUQ3J2rY8xpo+Slml+0bB6SJy2aI8eMvuEGWa6hUCgunGvVEFZ1LYW6PYVt02mQc188Y/vT5oOzCM1NvWmwTZWVwFn2txs8AIMhxwGACR3bc5Y6vAuIw9xYkNAgRGPkFwiUMi0u7GeREwrQ4ji+F9psnxt1oHFEqt3Jjo1pWgG2+QuLF7XKXD6dALjb4PsTuf60mG65qkHW3qJW7r/k/0rslqdbojc1UfZ3th8rN00LaWPN4JfY89dmZbES4CwK+SadinU/lCGp6f9o8RWXWo2qEnqrJPliHCZiTqcrrHWgyiXAeOjD+je2cHdCsG3JC3pialqsFQRjGAZ+GOF9jWg4Bb2se/4UjUZlK9U0hdtoVfhq9HkZxTWqlYegxvYAMr4YZ/qVFNwYgPUxraVwm40ylVohbFWC7t8tGOer2GiS4tNQfcKI+KatyEmdFY/brsjv7hFq7uN1DUQf9l6iLuvBHhdVlPzLQ1jSAC2Fm8vtbt2mjVSSim7G5LDwIxOE8mDFowJle+VFMw+yZmqJ8b0kAZ3G4jfJqB4wkmAU4ZTHC6z5d8g98jJbCmc9xwYPK+P4biIXbhhkGmLh8ysIre6WUwsjPXSWJ62VHtFSwqHCsHXIuQBBAlDpDGtQ7oTXjV/oepA8EcfykbNEndgGPv9d9a4TerwmhE/+b7Zy31dkbufX2HPHmZDXHakbNyQyLMOdsyzTbK/tkdyFN3UUmiaD2eD6KeBTyA5KbMT6/mIEg5IXKh5m/c+3OxlGF4AA9V03iDph0yOK0rmf5Mb6Ss5AdGOjPFwhXXIRps6vLdl85CZrzYkSS0O4IOu9FNY7ddCnYPVyQ32nUQwxd wvHzhBGG 9nEoueXC+ON+v3GzlOxSR/tZ1zOyfdfiVaUm2Ew3RP/fGWEKN/JQ0urYV03j++2ivTrA/7g55mwxHx6Dh+DzUx7fUAbKp/H4qJaEtGj9UZmSG0OPMLLfuz1itDxO0lUs1X6JuD/AQ8AE4tLMUQsiF/sY6iBMQ260dkqdukAHK0QFEdgDPknXSPtiOV3gUJ6t9NYPEIaU/F0H2SfkSCK69QvQm91RXruLpT+QQPV+rK0akYgHz+Xc3bQTTpwFcLlxSNfDUNjV/pWJprn4MvZ3NNMSx9gts7u5BYqWOghHtRYrBDCL9nzwg4gKDQjxleHgL0jr7Iv6RKSpqu1Mu3cgI+xPFqYT0QzrXSDIQyEl9t9YGFio= 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: List-Subscribe: List-Unsubscribe: In preparation for adding sysfs ABI to toggle memmap_on_memory semantics for drivers adding memory, export the mhp_supports_memmap_on_memory() helper. This allows drivers to check if memmap_on_memory support is available before trying to request it, and display an appropriate message if it isn't available. As part of this, remove the size argument to this - with recent updates to allow memmap_on_memory for larger ranges, and the internal splitting of altmaps into respective memory blocks, the size argument is meaningless. Cc: Andrew Morton Cc: David Hildenbrand Cc: Michal Hocko Cc: Oscar Salvador Cc: Dan Williams Cc: Dave Jiang Cc: Dave Hansen Cc: Huang Ying Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Signed-off-by: Vishal Verma --- include/linux/memory_hotplug.h | 6 ++++++ mm/memory_hotplug.c | 17 ++++++----------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 7d2076583494..ebc9d528f00c 100644 --- a/include/linux/memory_hotplug.h +++ b/include/linux/memory_hotplug.h @@ -121,6 +121,7 @@ struct mhp_params { bool mhp_range_allowed(u64 start, u64 size, bool need_mapping); struct range mhp_get_pluggable_range(bool need_mapping); +bool mhp_supports_memmap_on_memory(void); /* * Zone resizing functions @@ -262,6 +263,11 @@ static inline bool movable_node_is_enabled(void) return false; } +static bool mhp_supports_memmap_on_memory(void) +{ + return false; +} + static inline void pgdat_kswapd_lock(pg_data_t *pgdat) {} static inline void pgdat_kswapd_unlock(pg_data_t *pgdat) {} static inline void pgdat_kswapd_lock_init(pg_data_t *pgdat) {} diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 926e1cfb10e9..751664c519f7 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1325,7 +1325,7 @@ static inline bool arch_supports_memmap_on_memory(unsigned long vmemmap_size) } #endif -static bool mhp_supports_memmap_on_memory(unsigned long size) +bool mhp_supports_memmap_on_memory(void) { unsigned long vmemmap_size = memory_block_memmap_size(); unsigned long memmap_pages = memory_block_memmap_on_memory_pages(); @@ -1334,17 +1334,11 @@ static bool mhp_supports_memmap_on_memory(unsigned long size) * Besides having arch support and the feature enabled at runtime, we * need a few more assumptions to hold true: * - * a) We span a single memory block: memory onlining/offlinin;g happens - * in memory block granularity. We don't want the vmemmap of online - * memory blocks to reside on offline memory blocks. In the future, - * we might want to support variable-sized memory blocks to make the - * feature more versatile. - * - * b) The vmemmap pages span complete PMDs: We don't want vmemmap code + * a) The vmemmap pages span complete PMDs: We don't want vmemmap code * to populate memory from the altmap for unrelated parts (i.e., * other memory blocks) * - * c) The vmemmap pages (and thereby the pages that will be exposed to + * b) The vmemmap pages (and thereby the pages that will be exposed to * the buddy) have to cover full pageblocks: memory onlining/offlining * code requires applicable ranges to be page-aligned, for example, to * set the migratetypes properly. @@ -1356,7 +1350,7 @@ static bool mhp_supports_memmap_on_memory(unsigned long size) * altmap as an alternative source of memory, and we do not exactly * populate a single PMD. */ - if (!mhp_memmap_on_memory() || size != memory_block_size_bytes()) + if (!mhp_memmap_on_memory()) return false; /* @@ -1379,6 +1373,7 @@ static bool mhp_supports_memmap_on_memory(unsigned long size) return arch_supports_memmap_on_memory(vmemmap_size); } +EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory); static void __ref remove_memory_blocks_and_altmaps(u64 start, u64 size) { @@ -1512,7 +1507,7 @@ int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags) * Self hosted memmap array */ if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) && - mhp_supports_memmap_on_memory(memory_block_size_bytes())) { + mhp_supports_memmap_on_memory()) { ret = create_altmaps_and_memory_blocks(nid, group, start, size); if (ret) goto error;