Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp193739pxb; Thu, 27 Jan 2022 18:57:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZ7iwpmCR1npgharc8umjayyOrH8VnWf3sQJYBHOUs6b/RlVipDQzZue5Y5qJ/SnOlcFxq X-Received: by 2002:a17:907:d92:: with SMTP id go18mr4968351ejc.414.1643338672545; Thu, 27 Jan 2022 18:57:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643338672; cv=none; d=google.com; s=arc-20160816; b=a8Ff+XmbsP4KjvXjch5CSpjAIYkM8Sly467PRanSJtKsYqZH0cyJKxNufgiCg45+Lz JT/5sx5r7RlR+5I/QmZhViK/4KqllpxIwaYLmAu/kLnI8xVPYD2W48TyWbKiRR5rQ+2d vond1Q3XAGOZDBKIfedYo7hwBX1+m0ImgKf7GXRudvlzEDeDcBIONJYg09toLXtdv1sy DBZqf3LdI1QMU9hFzhdwOEUKF5uJWS4RdZyDTWYv6vLJdV+tTeoERmI5W6oszkamw1T5 AGummimVRbq/3+mqWtCc5WGJ7UE2H0uOe+6+3wjn5+mU+4lwFVK4X6onMTZLN+heuUyB rnQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FM8bZL7yzHwcPaQV1YCt9cC8HLjIEosujZ3SwBMP69k=; b=aeo/mPoOvBwOYD89y4t7bNbEpB6bFIFXS4aZlmdUj3iWmE3orAvHMUnc7OMmHfduxk zSRHp7n3JHKIPePEYlNW+NVR7PLYzWVtq5xdIrfQDWvS666tyWN/KDovr9R/N49ofYqk 5DkBEhUnN75rQR3oe24vD+/Nj2P+Ls+X8yl4rlvrKJ4n998BM+TGmHZGVMUkXT9YzyDY TWa6BLGDrm69NniVWVJZnNa+qEPC/691etwbS7hoaT8iZ7ZqTDVoeGJcTfY3AjInEVdw rkQVxTdcbV4pZhPH6F7eXhCXA7sM9qQYjl4N4anDFag56V1Qjb3GUp7KvLS4v8v/erY5 jCSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rYhwfCBh; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m19si2357169edd.539.2022.01.27.18.57.28; Thu, 27 Jan 2022 18:57:52 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=rYhwfCBh; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242150AbiA0Ni0 (ORCPT + 99 others); Thu, 27 Jan 2022 08:38:26 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:42644 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242172AbiA0Ngt (ORCPT ); Thu, 27 Jan 2022 08:36:49 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A2E7961C2A for ; Thu, 27 Jan 2022 13:36:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BF29C340E4; Thu, 27 Jan 2022 13:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643290608; bh=F9Lanb3MeXhx6oTm0RnhfrOZTdSI4PVnjIBtYmMfTyk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rYhwfCBh8kuMsZ/Hq3OY89hCboiUPMld7e3/cMHTJSpgI+zu3QSxPtvjD4+qxok7t ia7Lv2Zu81A01mzFbfauTXyNYhnJEZaa6fWWlnsqnX6F6N8EoJDPE8PQ3//pHRngz7 fsFyIgsNi8zd+j05EMVB2t0y50F+Ya0suL9r6ERiYptt+tVsYgihgA70O7CNfw7Xmp s5QkyUQGFNw3BVK3hiozx5ObbawbuSQEcV9We0bpQlzRbmvLChhA2MLTx/x8GZbezT LnyINsFPNNzwxUEq2lW6tVM40jWnK2V4Pf1h7p9KU+5JAcHOHWg2OG3dvD51WmBoID sqnuxUDBq/jJA== Date: Thu, 27 Jan 2022 15:36:39 +0200 From: Mike Rapoport To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, LKML , David Hildenbrand , Alexey Makhalov , Dennis Zhou , Eric Dumazet , Oscar Salvador , Tejun Heo , Christoph Lameter , Nico Pache , Wei Yang , Rafael Aquini , Michal Hocko Subject: Re: [PATCH 1/6] mm, memory_hotplug: make arch_alloc_nodedata independent on CONFIG_MEMORY_HOTPLUG Message-ID: References: <20220127085305.20890-1-mhocko@kernel.org> <20220127085305.20890-2-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220127085305.20890-2-mhocko@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 27, 2022 at 09:53:00AM +0100, Michal Hocko wrote: > From: Michal Hocko > > This is a preparatory patch and it doesn't introduce any functional > change. It merely pulls out arch_alloc_nodedata (and co) outside of > CONFIG_MEMORY_HOTPLUG because the following patch will need to call this > from the generic MM code. > > Acked-by: Rafael Aquini > Signed-off-by: Michal Hocko Acked-by: Mike Rapoport > --- > arch/ia64/mm/discontig.c | 2 - > include/linux/memory_hotplug.h | 119 ++++++++++++++++----------------- > 2 files changed, 59 insertions(+), 62 deletions(-) > > diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c > index 791d4176e4a6..8dc8a554f774 100644 > --- a/arch/ia64/mm/discontig.c > +++ b/arch/ia64/mm/discontig.c > @@ -608,7 +608,6 @@ void __init paging_init(void) > zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page)); > } > > -#ifdef CONFIG_MEMORY_HOTPLUG > pg_data_t *arch_alloc_nodedata(int nid) > { > unsigned long size = compute_pernodesize(nid); > @@ -626,7 +625,6 @@ void arch_refresh_nodedata(int update_node, pg_data_t *update_pgdat) > pgdat_list[update_node] = update_pgdat; > scatter_node_data(); > } > -#endif > > #ifdef CONFIG_SPARSEMEM_VMEMMAP > int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > index be48e003a518..4355983b364d 100644 > --- a/include/linux/memory_hotplug.h > +++ b/include/linux/memory_hotplug.h > @@ -16,6 +16,65 @@ struct memory_group; > struct resource; > struct vmem_altmap; > > +#ifdef CONFIG_HAVE_ARCH_NODEDATA_EXTENSION > +/* > + * For supporting node-hotadd, we have to allocate a new pgdat. > + * > + * If an arch has generic style NODE_DATA(), > + * node_data[nid] = kzalloc() works well. But it depends on the architecture. > + * > + * In general, generic_alloc_nodedata() is used. > + * Now, arch_free_nodedata() is just defined for error path of node_hot_add. > + * > + */ > +extern pg_data_t *arch_alloc_nodedata(int nid); > +extern void arch_free_nodedata(pg_data_t *pgdat); > +extern void arch_refresh_nodedata(int nid, pg_data_t *pgdat); > + > +#else /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */ > + > +#define arch_alloc_nodedata(nid) generic_alloc_nodedata(nid) > +#define arch_free_nodedata(pgdat) generic_free_nodedata(pgdat) > + > +#ifdef CONFIG_NUMA > +/* > + * XXX: node aware allocation can't work well to get new node's memory at this time. > + * Because, pgdat for the new node is not allocated/initialized yet itself. > + * To use new node's memory, more consideration will be necessary. > + */ > +#define generic_alloc_nodedata(nid) \ > +({ \ > + kzalloc(sizeof(pg_data_t), GFP_KERNEL); \ > +}) > +/* > + * This definition is just for error path in node hotadd. > + * For node hotremove, we have to replace this. > + */ > +#define generic_free_nodedata(pgdat) kfree(pgdat) > + > +extern pg_data_t *node_data[]; > +static inline void arch_refresh_nodedata(int nid, pg_data_t *pgdat) > +{ > + node_data[nid] = pgdat; > +} > + > +#else /* !CONFIG_NUMA */ > + > +/* never called */ > +static inline pg_data_t *generic_alloc_nodedata(int nid) > +{ > + BUG(); > + return NULL; > +} > +static inline void generic_free_nodedata(pg_data_t *pgdat) > +{ > +} > +static inline void arch_refresh_nodedata(int nid, pg_data_t *pgdat) > +{ > +} > +#endif /* CONFIG_NUMA */ > +#endif /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */ > + > #ifdef CONFIG_MEMORY_HOTPLUG > struct page *pfn_to_online_page(unsigned long pfn); > > @@ -154,66 +213,6 @@ int add_pages(int nid, unsigned long start_pfn, unsigned long nr_pages, > struct mhp_params *params); > #endif /* ARCH_HAS_ADD_PAGES */ > > -#ifdef CONFIG_HAVE_ARCH_NODEDATA_EXTENSION > -/* > - * For supporting node-hotadd, we have to allocate a new pgdat. > - * > - * If an arch has generic style NODE_DATA(), > - * node_data[nid] = kzalloc() works well. But it depends on the architecture. > - * > - * In general, generic_alloc_nodedata() is used. > - * Now, arch_free_nodedata() is just defined for error path of node_hot_add. > - * > - */ > -extern pg_data_t *arch_alloc_nodedata(int nid); > -extern void arch_free_nodedata(pg_data_t *pgdat); > -extern void arch_refresh_nodedata(int nid, pg_data_t *pgdat); > - > -#else /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */ > - > -#define arch_alloc_nodedata(nid) generic_alloc_nodedata(nid) > -#define arch_free_nodedata(pgdat) generic_free_nodedata(pgdat) > - > -#ifdef CONFIG_NUMA > -/* > - * If ARCH_HAS_NODEDATA_EXTENSION=n, this func is used to allocate pgdat. > - * XXX: kmalloc_node() can't work well to get new node's memory at this time. > - * Because, pgdat for the new node is not allocated/initialized yet itself. > - * To use new node's memory, more consideration will be necessary. > - */ > -#define generic_alloc_nodedata(nid) \ > -({ \ > - kzalloc(sizeof(pg_data_t), GFP_KERNEL); \ > -}) > -/* > - * This definition is just for error path in node hotadd. > - * For node hotremove, we have to replace this. > - */ > -#define generic_free_nodedata(pgdat) kfree(pgdat) > - > -extern pg_data_t *node_data[]; > -static inline void arch_refresh_nodedata(int nid, pg_data_t *pgdat) > -{ > - node_data[nid] = pgdat; > -} > - > -#else /* !CONFIG_NUMA */ > - > -/* never called */ > -static inline pg_data_t *generic_alloc_nodedata(int nid) > -{ > - BUG(); > - return NULL; > -} > -static inline void generic_free_nodedata(pg_data_t *pgdat) > -{ > -} > -static inline void arch_refresh_nodedata(int nid, pg_data_t *pgdat) > -{ > -} > -#endif /* CONFIG_NUMA */ > -#endif /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */ > - > void get_online_mems(void); > void put_online_mems(void); > > -- > 2.30.2 > -- Sincerely yours, Mike.