From mboxrd@z Thu Jan 1 00:00:00 1970 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 83355C001DE for ; Mon, 24 Jul 2023 05:56:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5F296B0074; Mon, 24 Jul 2023 01:56:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0F186B0075; Mon, 24 Jul 2023 01:56:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D6E06B0078; Mon, 24 Jul 2023 01:56:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8B4576B0074 for ; Mon, 24 Jul 2023 01:56:08 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5B5DD408C7 for ; Mon, 24 Jul 2023 05:56:08 +0000 (UTC) X-FDA: 81045444816.17.DCD6CC7 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf13.hostedemail.com (Postfix) with ESMTP id BE3B520006 for ; Mon, 24 Jul 2023 05:56:05 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HXuAO9yT; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf13.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690178166; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8m75jtH8ImpkUj8mxLAwXsEHMMk5w0y5hPjJOCy54PY=; b=Tlb5u0Uu84v8fmCUTaYeMcrrBzuvPzVpi78CrhzZ5pTKo3Qiusa59JAUJYDpj3t5a/QwT0 4N8t02brYBVT6XtIsKdXafylXsaJKa1hHQ+vSWNQjLuh3+SwQl4zV9xcjwzyJqsebrOHdu smI7RXeWV8+d1NT8p52JsiL1DU84xdk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HXuAO9yT; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf13.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690178166; a=rsa-sha256; cv=none; b=Z/Q3cTnQDt37LxbejRqnbWip1+1+JiuN5e/Vq1BJ76quscFCEiE8BxoY7fwdRN9AsvLoQ7 FwDMTtmiB0i/FcdEgk8AwJq/thhghK8uldR82k/BhPSzadKJZQ1l9BzBGgn7agyjIkSiVU Uq8S1rlqcB7ounCLapQw9Vba2/FdeFc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690178165; x=1721714165; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=yCJ1BXzutgoy0IBd25HUHJtrVt+SpnQcvmmJECP+rAk=; b=HXuAO9yTuYpYsr8ah4Rf8UTKGvqYmCgADD1VTe3FLci2sJXfERyBaFjj ZfpabdvwqHShObMYsuknQOsve6wjyIEs0rnfXueOEJw8dS7cyUzMg/8WU gLZ7ajK4mqbSpqDxm+Da3UkMQ3jVxJNIvsLz3hzTYM5EPShoQ/tJH/GZb NnjvB2Mf5XCkYDDuaPb6W7OmkHt0e0XffqwvUlJR0nZqRYnyh+hR2wY37 TuFHTTbqmI5Gk5+WyZWjVwtreUe6URizh9+bIGk/qfd1wnEZXQybLMMMI OtYUxyjjFH27W8AfA0F3RoK72l3phVmv6F1Kaqod0x0h8rs6ysMZOL395 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="357354455" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="357354455" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2023 22:56:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="899393120" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="899393120" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2023 22:56:00 -0700 From: "Huang, Ying" To: Vishal Verma Cc: Andrew Morton , David Hildenbrand , Oscar Salvador , Dan Williams , Dave Jiang , , , , , Dave Hansen , "Aneesh Kumar K.V" , Jonathan Cameron , Jeff Moyer Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks In-Reply-To: <20230720-vv-kmem_memmap-v2-2-88bdaab34993@intel.com> (Vishal Verma's message of "Thu, 20 Jul 2023 01:14:23 -0600") References: <20230720-vv-kmem_memmap-v2-0-88bdaab34993@intel.com> <20230720-vv-kmem_memmap-v2-2-88bdaab34993@intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Date: Mon, 24 Jul 2023 13:54:23 +0800 Message-ID: <87wmyp26sw.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: BE3B520006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ddpxs1tbq5bk5p6pryospsb91ggxsams X-HE-Tag: 1690178165-247042 X-HE-Meta: U2FsdGVkX1/BsAHclNfZIna+9rN0hXeccAYiq2kxP54cZ1NvygQU67q62OOuiK41QIoIWsoC3iKbqVKkyL4tgM4upxtOJvjXeBTCPywI2XgaDRXz7pkulPvtxyImS3/SaU/gniM31VeNXrAi5JbXrRWe/WWljc6tXbSCCa+mymf+WOnYZdRkqCBCZRMMfcpn1spWG4WZHaZA5QOT3uye48xxm8YMI2eZBqKg36cYA2qajmPX/nt63xzwOdDtuDkMYexQVYSXdlV7tKvSfVk4OQM+5gVozIeT+V2zqEn7RsliD14hO0P21zTJwa+eYwFpkNM7YwzATdFfn/FxKQ1uI/2kGUrjk+9k19ju47N1d4LxM7EqHZqrz0SdCkwkPIYZo6GJtWkkbxoQLj/hlGx0oHDkZEcY9lgxhlMg+zEczdQATHchqJwxrzmE1gnD6p/7PHPQEH253Gtj8FuTPkbhmDpSYWOZZDQJ9flqhNn/gl90QbpdLYbvzsNzp3xBENYvupnNI9G3wJWOEXwMRXwiEPSHsQdEhqWesGp3FGpWlfsvaAvzTEPSUh6BBTWuESltYwbPiDfKN2j4CjZ3mHtFNtc+QF9+/E9yFoMU5+hVx0EzuLMyADGcN+59QNWwbV9hjVYylaMAWGqB2gl0FnV78dRE0D6LPrZhuMT3TXEigkt9KR9S6LD8r9gRq6bjnXURyn66OoMyZKdfrs+KUu+JvzP16WastY+872/Bt0bb5q/ZpBT98gDfCc0YvfKUBlDP38czfi9h4TNZs6WF0XUdBHC06Gd7n1CCvqLG3Oah4FhSvp55pN5/CddNKmt9HoBVQoEIVG5VP8l+Tsft88FC+32qRiTDpdOeOekm1M2gosu3e+P2NQMrtaeqRekmXDNDU9/zRkPlI5JDasXIJ9fd7Ir8n6jNnaV39mx+wwVzaZU6QXlwALvaUZeX6pwNIRgrOW2WrhFtlpZw9vJm7Sv o4C4yGov fBiEypvsvO/v7IkpMZPNjK7LUNjiPsae2oiRU5AhWG1RQ5O7eChfL69bNkrDP2DT2QITOE3nQ2dN5/DWdgDnyozMpi7MGyAczzeC7mbKgfqits7KPsAz86Ly+h/9cO4ykb9wTjOutGL5RHSi3F7jyV36RbbE68tV1/QXTAljuAdWnh6DQcX2VZNIyrLj8EAB+5GyOQGEIwH6MZRXRSA2GpB+ZfxoaXUcLAX3p6bfiIvfnj7/dt08fEPGo6WPAt2liiK6EavJ+4FfEtEFzas5ZqVRXeWexa6xN4H/c3VTzj0ipPft4fRPfI7YufQ== 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: Vishal Verma writes: > The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is currently > restricted to 'memblock_size' chunks of memory being added. Adding a > larger span of memory precludes memmap_on_memory semantics. > > For users of hotplug such as kmem, large amounts of memory might get > added from the CXL subsystem. In some cases, this amount may exceed the > available 'main memory' to store the memmap for the memory being added. > In this case, it is useful to have a way to place the memmap on the > memory being added, even if it means splitting the addition into > memblock-sized chunks. > > Change add_memory_resource() to loop over memblock-sized chunks of > memory if caller requested memmap_on_memory, and if other conditions for > it are met,. Teach try_remove_memory() to also expect that a memory > range being removed might have been split up into memblock sized chunks, > and to loop through those as needed. > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Oscar Salvador > Cc: Dan Williams > Cc: Dave Jiang > Cc: Dave Hansen > Cc: Huang Ying > Suggested-by: David Hildenbrand > Signed-off-by: Vishal Verma > --- > mm/memory_hotplug.c | 154 +++++++++++++++++++++++++++++++--------------------- > 1 file changed, 91 insertions(+), 63 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index e9bcacbcbae2..20456f0d28e6 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1286,6 +1286,35 @@ bool mhp_supports_memmap_on_memory(unsigned long size) > } > EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory); > > +static int add_memory_create_devices(int nid, struct memory_group *group, > + u64 start, u64 size, mhp_t mhp_flags) > +{ > + struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) }; > + struct vmem_altmap mhp_altmap = {}; > + int ret; > + > + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY)) { > + mhp_altmap.free = PHYS_PFN(size); > + mhp_altmap.base_pfn = PHYS_PFN(start); > + params.altmap = &mhp_altmap; > + } > + > + /* call arch's memory hotadd */ > + ret = arch_add_memory(nid, start, size, ¶ms); > + if (ret < 0) > + return ret; > + > + /* create memory block devices after memory was added */ > + ret = create_memory_block_devices(start, size, mhp_altmap.alloc, > + group); > + if (ret) { > + arch_remove_memory(start, size, NULL); > + return ret; > + } > + > + return 0; > +} > + > /* > * NOTE: The caller must call lock_device_hotplug() to serialize hotplug > * and online/offline operations (triggered e.g. by sysfs). > @@ -1294,11 +1323,10 @@ EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory); > */ > int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags) > { > - struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) }; > + unsigned long memblock_size = memory_block_size_bytes(); > enum memblock_flags memblock_flags = MEMBLOCK_NONE; > - struct vmem_altmap mhp_altmap = {}; > struct memory_group *group = NULL; > - u64 start, size; > + u64 start, size, cur_start; > bool new_node = false; > int ret; > > @@ -1339,27 +1367,20 @@ 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) { > - if (!mhp_supports_memmap_on_memory(size)) { > - ret = -EINVAL; > + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) && > + mhp_supports_memmap_on_memory(memblock_size)) { > + for (cur_start = start; cur_start < start + size; > + cur_start += memblock_size) { > + ret = add_memory_create_devices(nid, group, cur_start, > + memblock_size, > + mhp_flags); > + if (ret) > + goto error; > + } > + } else { > + ret = add_memory_create_devices(nid, group, start, size, mhp_flags); > + if (ret) > goto error; Another choice to organize code is to use different step (memblock_size vs. size) in "for" loop. It's not necessary in this patchset. It appears that we cannot create 1GB mapping if we put memmap on memory now, right? If so, is it doable to support that via separating creating memory mapping from arch_add_memory()? > - } > - mhp_altmap.free = PHYS_PFN(size); > - mhp_altmap.base_pfn = PHYS_PFN(start); > - params.altmap = &mhp_altmap; > - } > - > - /* call arch's memory hotadd */ > - ret = arch_add_memory(nid, start, size, ¶ms); > - if (ret < 0) > - goto error; > - > - /* create memory block devices after memory was added */ > - ret = create_memory_block_devices(start, size, mhp_altmap.alloc, > - group); > - if (ret) { > - arch_remove_memory(start, size, NULL); > - goto error; > } > > if (new_node) { > @@ -2035,12 +2056,38 @@ void try_offline_node(int nid) > } > EXPORT_SYMBOL(try_offline_node); > > -static int __ref try_remove_memory(u64 start, u64 size) > +static void __ref __try_remove_memory(int nid, u64 start, u64 size, > + struct vmem_altmap *altmap) > { > - struct vmem_altmap mhp_altmap = {}; > - struct vmem_altmap *altmap = NULL; > - unsigned long nr_vmemmap_pages; > - int rc = 0, nid = NUMA_NO_NODE; > + /* remove memmap entry */ > + firmware_map_remove(start, start + size, "System RAM"); If mhp_supports_memmap_on_memory(), we will call firmware_map_add_hotplug() for whole range. But here we may call firmware_map_remove() for part of range. Is it OK? -- Best Regards, Huang, Ying > + > + /* > + * Memory block device removal under the device_hotplug_lock is > + * a barrier against racing online attempts. > + */ > + remove_memory_block_devices(start, size); > + > + mem_hotplug_begin(); > + > + arch_remove_memory(start, size, altmap); > + > + if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) { > + memblock_phys_free(start, size); > + memblock_remove(start, size); > + } > + > + release_mem_region_adjustable(start, size); > + > + if (nid != NUMA_NO_NODE) > + try_offline_node(nid); > + > + mem_hotplug_done(); > +} > + > +static int try_remove_memory(u64 start, u64 size) > +{ > + int rc, nid = NUMA_NO_NODE; > > BUG_ON(check_hotplug_memory_range(start, size)); > > @@ -2058,20 +2105,21 @@ static int __ref try_remove_memory(u64 start, u64 size) > return rc; > > /* > - * We only support removing memory added with MHP_MEMMAP_ON_MEMORY in > - * the same granularity it was added - a single memory block. > + * For memmap_on_memory, the altmaps could have been added on > + * a per-memblock basis. Loop through the entire range if so, > + * and remove each memblock and its altmap > */ > if (mhp_memmap_on_memory()) { > - nr_vmemmap_pages = walk_memory_blocks(start, size, NULL, > - get_nr_vmemmap_pages_cb); > - if (nr_vmemmap_pages) { > - if (size != memory_block_size_bytes()) { > - pr_warn("Refuse to remove %#llx - %#llx," > - "wrong granularity\n", > - start, start + size); > - return -EINVAL; > - } > + unsigned long memblock_size = memory_block_size_bytes(); > + struct vmem_altmap mhp_altmap = {}; > + struct vmem_altmap *altmap; > + u64 cur_start; > > + for (cur_start = start; cur_start < start + size; > + cur_start += memblock_size) { > + unsigned long nr_vmemmap_pages = > + walk_memory_blocks(start, memblock_size, NULL, > + get_nr_vmemmap_pages_cb); > /* > * Let remove_pmd_table->free_hugepage_table do the > * right thing if we used vmem_altmap when hot-adding > @@ -2079,33 +2127,13 @@ static int __ref try_remove_memory(u64 start, u64 size) > */ > mhp_altmap.alloc = nr_vmemmap_pages; > altmap = &mhp_altmap; > + __try_remove_memory(nid, cur_start, memblock_size, > + altmap); > } > + } else { > + __try_remove_memory(nid, start, size, NULL); > } > > - /* remove memmap entry */ > - firmware_map_remove(start, start + size, "System RAM"); > - > - /* > - * Memory block device removal under the device_hotplug_lock is > - * a barrier against racing online attempts. > - */ > - remove_memory_block_devices(start, size); > - > - mem_hotplug_begin(); > - > - arch_remove_memory(start, size, altmap); > - > - if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) { > - memblock_phys_free(start, size); > - memblock_remove(start, size); > - } > - > - release_mem_region_adjustable(start, size); > - > - if (nid != NUMA_NO_NODE) > - try_offline_node(nid); > - > - mem_hotplug_done(); > return 0; > }