Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Date:   Thu, 5 Oct 2023 14:20:56 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Vishal Verma <vishal.l.verma@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Hildenbrand <david@redhat.com>,
        "Oscar Salvador" <osalvador@suse.de>,
        Dan Williams <dan.j.williams@intel.com>,
        "Dave Jiang" <dave.jiang@intel.com>
CC:     <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
        <nvdimm@lists.linux.dev>, <linux-cxl@vger.kernel.org>,
        Huang Ying <ying.huang@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
        Michal Hocko <mhocko@suse.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Jeff Moyer <jmoyer@redhat.com>,
        Vishal Verma <vishal.l.verma@intel.com>
Subject: RE: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory
 requests across memblocks
Message-ID: <651f28b87e6a8_ae7e7294b8@dwillia2-xfh.jf.intel.com.notmuch>
References: <20231005-vv-kmem_memmap-v5-0-a54d1981f0a3@intel.com>
 <20231005-vv-kmem_memmap-v5-1-a54d1981f0a3@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20231005-vv-kmem_memmap-v5-1-a54d1981f0a3@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?udKZmivdH62PRMPBs8MV6FiNulujzELg0pUhClUH3qu1/v+lLKaKHh4UyPdh?=
 =?us-ascii?Q?HfTR+NmJNqRNkwzdEqBL2l8gi6XHQYWBXcUNvGeqK6X7AlVOPkDqXQ/wklhX?=
 =?us-ascii?Q?hr4euvhXDUpTgXu/C0jGEAvq9kYDiFpTgH+SwtXDJslaIk6NdZ4O9+J8Rgio?=
 =?us-ascii?Q?rfKVuc+R+sYdJWiS5KefSy8O/PjfIOBUfx0TFen+jQ36XkEGrxzhS10GuRwh?=
 =?us-ascii?Q?wVBud0nPGF4g+NLbAEQ+5dr/THfc6v03VuCXfynfhPv2JC6OeTLpfK3piQjv?=
 =?us-ascii?Q?U5F0aj9TP2yuaAHpmI1sy3q3DFeiiFzk0g4DNgh0aiVs+o9rXXScnvKnkfqd?=
 =?us-ascii?Q?jrUx5N2evjoA66Dl5rjrSQ5emAJYyX6kAyssDh4AIpMVFLYxPBRGE7rA9tNc?=
 =?us-ascii?Q?89S0Oyo4F479B+Kk3fhuzm7WGW/68I/TKqCsXvKM9vpI0vL2ujgtYv62Hxtc?=
 =?us-ascii?Q?PEsTqMu/9OW+lfhSun14f+cWrLKQjCBofxqxcR2scYonfaCCjxljwxn3P0pM?=
 =?us-ascii?Q?0BEWh6olYQ5VleVGc5IUr7q41Fli/I9RTRU8rTDDThXXmInicXwPy5jxfwBI?=
 =?us-ascii?Q?mTf7HRCJw0W7sBXz3UJCdMOO61Cfjn/8CVTdYcWhaJHqq1+8OMsu8hHSR29p?=
 =?us-ascii?Q?CKgjbauCvxUY8tPv6TZlgIwmiVnr/G+NWSuhbi9ZLquqcbH2Sak1elzG4MNS?=
 =?us-ascii?Q?4AHJ0SO4BLVXc+GBTpMhAQzX8SuTLSVomjGUYhcAHQmHDxAgJENpmEKuVBue?=
 =?us-ascii?Q?2vJST4UYSgb0zmqwYhvCclRzwyRAtF0JZLgw3Y6XmFDTUnJEgTGXpboibdTl?=
 =?us-ascii?Q?8SpnUDqMnnzf2xPX8aS4i3gWnxoHP/AqAYRGhRIoHZbyeixdosXV04wXoWC1?=
 =?us-ascii?Q?QQbzZG0V458rS6b5pn/NYmZ/IIxTIu3cPWHozQAMNRYYn3F4atKgmw3bnLm8?=
 =?us-ascii?Q?wFWuodXMghwhTKiRx7mS2rl2CyOph9G5NQEmKYWcM0Cc5cxXDXPCBgiZwCks?=
 =?us-ascii?Q?3dkqTcowozEhg2iVEzKPiSnymS8rDfNEfof18wl4JKjx9NyJ6e3vkyPBkRJO?=
 =?us-ascii?Q?B6879skfKg9r3yBrPI2Xe7YXngfD9ce94qnwAW8g+IDWjFs31jCCSz3frb+n?=
 =?us-ascii?Q?7gqD+DVrmAhIrAPEvabDjs0uhPaHlH0Rq3kBvA44W708ftFi0aoQq4VfYbmQ?=
 =?us-ascii?Q?Uha3ZU108J6mkTS2wA/+ytsOt+IWuBgx+lX6ydnR7p/caM3C2XqQVnyv3k2A?=
 =?us-ascii?Q?eaKhaXaataR/To6zTEwEw8x7TgjzwKWi0RSCSDuKvbEtvXLv/9iWta1uquZ9?=
 =?us-ascii?Q?uu6M+MWJQciHmW7NxjMGFKR9H6nZSL/ch5eqqqKHZOtLgAQLf+2T1hSYCmMT?=
 =?us-ascii?Q?vnQBthRN4XY4EwPX0XcuQWBzSn6qpOKcFYsAEee4not2eUwpCjxyBinRBC2L?=
 =?us-ascii?Q?7xO95UzHTXE0N7Db/MOitj6Y0xPVVW5YeBGkuUXaYQ/QdnfzWwoQvrFu/eci?=
 =?us-ascii?Q?mZCHRDHJanNaApgqdVK9aSjLY1MOORuje1MxLA/md/AhkgutQAJ/zrFJ7Ivz?=
 =?us-ascii?Q?rYhMF/OyRaA6ekveD0WfOSFwdm+a2w+51rLYFhgF0Dgbx5CU8+Qg5EkVPZSO?=
 =?us-ascii?Q?lA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 4048eb08-3ab9-4bcc-e725-08dbc5e8f8d8
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2023 21:21:00.3008
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: PxGpK//FuWMGyRsg2Wspe201ZMA0dVInH41bQ4krFJzENps70zYkMudHltOxzw1n+W6uJPpGo6ogiBJ2cQvbrPbLJPUYl9UTeAeN6G0EsBs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB7982
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 05 Oct 2023 14:21:30 -0700 (PDT)

Vishal Verma wrote:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is 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 <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Huang Ying <ying.huang@intel.com>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ---
>  mm/memory_hotplug.c | 162 ++++++++++++++++++++++++++++++++--------------------
>  1 file changed, 99 insertions(+), 63 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index f8d3e7427e32..77ec6f15f943 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1380,6 +1380,44 @@ static bool mhp_supports_memmap_on_memory(unsigned long size)
>  	return arch_supports_memmap_on_memory(vmemmap_size);
>  }
>  
> +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 = {
> +		.base_pfn =  PHYS_PFN(start),
> +		.end_pfn  =  PHYS_PFN(start + size - 1),
> +	};
> +	int ret;
> +
> +	if ((mhp_flags & MHP_MEMMAP_ON_MEMORY)) {
> +		mhp_altmap.free = memory_block_memmap_on_memory_pages();
> +		params.altmap = kmalloc(sizeof(struct vmem_altmap), GFP_KERNEL);
> +		if (!params.altmap)
> +			return -ENOMEM;
> +
> +		memcpy(params.altmap, &mhp_altmap, sizeof(mhp_altmap));

Isn't this just open coded kmemdup()?

Other than that, I am not seeing anything else to comment on, you can add:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>