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 47647C001E0 for ; Mon, 14 Aug 2023 06:46:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8AA48D0002; Mon, 14 Aug 2023 02:46:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3AC68D0001; Mon, 14 Aug 2023 02:46:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 903AA8D0002; Mon, 14 Aug 2023 02:46:57 -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 7DDA08D0001 for ; Mon, 14 Aug 2023 02:46:57 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3D618160AAB for ; Mon, 14 Aug 2023 06:46:57 +0000 (UTC) X-FDA: 81121777674.17.9CCC9E6 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf28.hostedemail.com (Postfix) with ESMTP id 694F2C0010 for ; Mon, 14 Aug 2023 06:46:54 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Ij6UID2M; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691995615; 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=q0e9rwWIWjg/ZDO7rCx96YDeMVzkuUww37+q5f0R3BI=; b=qGv2OSXGlMTEMX8Pi3ngWPRpJyzssPAZy+18VqF+/iBkp8rfFgh4sRwo8eOOZZIzmZ9qyh OZPQzy1zL4sGJyA3QnvcmgbD1Ge0NW3xf8Yh7qFkDcjEd5sAVIhI+IrC3Dpx/pBmha5IFK UfMSrm0rK+eh0hp/M7LZMcOpfPuP/rI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691995615; a=rsa-sha256; cv=none; b=vu081zx5VKRrjtp77A+PR3cEaidOoRq82gasA6pOg/+PKfBZ0TURT3BxvW2M5LRY8Z1P3p vi03tQa+5nzVqwWnE1vvlDaP/twhsWz49CteFR8Gj3012dhfRlIhQYlIdNK6B1fMDmKn6J I4Ozpj6vIq+QTHOcHIXFvld5uPK8Ago= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Ij6UID2M; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691995614; x=1723531614; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=C0TDfkgSSHw3hPvjktNVzuGscNvAIMHKbLVHz69LTMQ=; b=Ij6UID2MFWK6OM8YP/XngeINTmHbneYucQ8FjzeBBDM9OOjx/hD8Wbz+ nA6BjXKgbl7s60Qmnn8HO2Ahz4+UrdZmlL1jDeQnlyPtaO6ETeZoncnmq 9rPJ23ekSNtItybHqVOZcylhcakKjqQ/v/rKU2P46rzqPkYbz2069XrhE Q0TpA3ehq4R9Eo1Cmnr4Zo1B81Ib5qFNf3iCdGGh6cFq+ilD/JZswAfvJ mVTrq330Yvf3H+Pi4Sh+/P/Oc1TB4blrwWMelVQA073HsJnEsDWHMqrQX wkGXHeUeKCvaUD+ZeQQeNXNeFbBcPAhXHU1E/iI/cKRV4dwODOPKvrVvz w==; X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="356939100" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="356939100" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2023 23:46:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="847527023" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="847527023" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2023 23:46:48 -0700 From: "Huang, Ying" To: "Verma, Vishal L" Cc: "david@redhat.com" , "Jiang, Dave" , "linux-mm@kvack.org" , "osalvador@suse.de" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "dave.hansen@linux.intel.com" , "Jonathan.Cameron@Huawei.com" , "nvdimm@lists.linux.dev" , "aneesh.kumar@linux.ibm.com" , "jmoyer@redhat.com" , "linux-cxl@vger.kernel.org" , Greg Kroah-Hartman , Mike Rapoport , Bernhard Walle Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks References: <20230720-vv-kmem_memmap-v2-0-88bdaab34993@intel.com> <20230720-vv-kmem_memmap-v2-2-88bdaab34993@intel.com> <87wmyp26sw.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 14 Aug 2023 14:45:11 +0800 In-Reply-To: (Vishal L. Verma's message of "Wed, 2 Aug 2023 14:08:20 +0800") Message-ID: <87jzty9l6w.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 694F2C0010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 7igg691a9jwiy3dxkkmjk4yfrt5aa6pb X-HE-Tag: 1691995614-317216 X-HE-Meta: U2FsdGVkX18zKjnojCHZpy7O4uvNykZFUprrqDY+fP0Eh0kCy+1Ta6wl8D9AiDRVi9EUAHcV4QbTwT69+G50HYa7/jBLoH1dzGA/pwTrZMZ8w+pNvL52k1PYYgpu72vYI6dU2lJpTSN7IMexiv70XPI1t+tIa014POU+Tq+lSnxrhq1oRLmZzscUV6rhEatyr4gnBoftvBuCHHbmmyIaMXr7ZfSUdqcLlkzDYWsX/fD9SGxBM1KWKaf0YwvACaFOY/FyTrT4IT4R/GuhppQQ9BxJEzhGMF3s9roQEfdPEkIMg65MPPzQyO4hxE+9N2N13UkaWsQt2Kc9EOw6QUCVng3LgOA2MehwrFpLim9w4ZQeGOQ9YGDotw1NtlfzZ/kzflGGmzQuBKGCmlKDrl+jFEq+3DSZuuy4w7lN2f915H0xRlm7whD7cN7XDQ4hLvkX2wF1W773Wv0hya0W/7sAH9tJ+45Jji5DVs11JxRSJBSVgSTNeGjoN/KA6z/lgKykzosXv4GJ+RY5tGfCrL8lngLrOkoMs/gFAgp6V3WcwLczb2JWI5O3rUtcm+/pieGUYSaEGnUXT+pd5NVQOlEWk+dLxPaLtUMScDPus4yWc8DV4GO7DvZyZ5Kb1M8/jvB7hnf8k3CIBEzUtKdX5FbPb2bRoB8B7ADtiahhzInzHVm4d6aVbK9d3ssoWBfRgfvl9QB1JVyksG3uanqxQm7iq/6pBFiw+ySjV/VYYiSno3xfw4q47Jc7kNQxYUnyxBXwqv9FWA2+QtNz3dSFfE+4BOhG4UdH77N3FrF10CrSMNIidV4ZpsUjQCbwW63F6EQUxPZX/mvmnkfnEHdOARUA5Gl5Ia4GpCtTW8wAT9DSQddEp1LdMiBuA2M2dlttOhmgyAg8VLwTSZafhpyXXWD56XQQwA3cWNGJ2CnEjJF3j9CBLSIBzmcWhviyuQ/fsk4OGC8EA8rqO40P+X0th9m 6k6iBc5r cFTcpBO7rmxjtnoqsbwIsx7COa/7h4UftyOH5+3vEd0P/qWMAepbQM7nC32HXYERxBhQEkAQXNIh2nPjey06zo04tWTevrUjb06Yte3b9Qk42m8mZus+HYoQhB9BPkRkC4MYEghh8nFVVYyUaEDIPm1uIvDqHUCvW9XtooXUQSAG1DoPjarcaoeWG76ZKr7nyxISVOW4d8hp8lODgFsCvmcmEEGBgvzzdIqwniNAEIssUES8haO7yxpS/4GRumtP9gXEIXRUyZZPe6oA= 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: "Verma, Vishal L" writes: > On Mon, 2023-07-24 at 13:54 +0800, Huang, Ying wrote: >> Vishal Verma writes: >> >> > >> > @@ -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? >> > > Good point, this is a discrepancy in the add vs remove path. Can the > firmware memmap entries be moved up a bit in the add path, and is it > okay to create these for each memblock? Or should these be for the > whole range? I'm not familiar with the implications. (I've left it as > is for v3 for now, but depending on the direction I can update in a > future rev). Cced more firmware map developers and maintainers. Per my understanding, we should create one firmware memmap entry for each memblock. -- Best Regards, Huang, Ying