All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Zhenguo Yao <yaozhenguo1@gmail.com>,
	mike.kravetz@oracle.com, mpe@ellerman.id.au,
	benh@kernel.crashing.org, paulus@samba.org, corbet@lwn.net,
	akpm@linux-foundation.org, yaozhenguo@jd.com,
	willy@infradead.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-mm@kvack.org,
	llvm@lists.linux.dev
Subject: Re: [PATCH v7] hugetlbfs: Extend the definition of hugepages parameter to support node allocation
Date: Wed, 29 Sep 2021 15:27:18 -0700	[thread overview]
Message-ID: <YVToRpjbg5mO0bru@kernel.org> (raw)
In-Reply-To: <YVS9VhrAuKE2YdbF@archlinux-ax161>

On Wed, Sep 29, 2021 at 12:24:06PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 27, 2021 at 06:41:49PM +0800, Zhenguo Yao wrote:
> > We can specify the number of hugepages to allocate at boot. But the
> > hugepages is balanced in all nodes at present. In some scenarios,
> > we only need hugepages in one node. For example: DPDK needs hugepages
> > which are in the same node as NIC. if DPDK needs four hugepages of 1G
> > size in node1 and system has 16 numa nodes. We must reserve 64 hugepages
> > in kernel cmdline. But, only four hugepages are used. The others should
> > be free after boot. If the system memory is low(for example: 64G), it will
> > be an impossible task. So, Extending hugepages parameter to support
> > specifying hugepages at a specific node.
> > For example add following parameter:
> > 
> > hugepagesz=1G hugepages=0:1,1:3
> > 
> > It will allocate 1 hugepage in node0 and 3 hugepages in node1.
> > 
> > Signed-off-by: Zhenguo Yao <yaozhenguo1@gmail.com>
> 
> <snip>
> 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 95dc7b83381f..ca00676a1bdd 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -66,6 +66,7 @@ static struct hstate * __initdata parsed_hstate;
> >  static unsigned long __initdata default_hstate_max_huge_pages;
> >  static bool __initdata parsed_valid_hugepagesz = true;
> >  static bool __initdata parsed_default_hugepagesz;
> > +static unsigned int default_hugepages_in_node[MAX_NUMNODES] __initdata;
> >  
> >  /*
> >   * Protects updates to hugepage_freelists, hugepage_activelist, nr_huge_pages,
> > @@ -2868,33 +2869,41 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
> >  	return ERR_PTR(-ENOSPC);
> >  }
> >  
> > -int alloc_bootmem_huge_page(struct hstate *h)
> > +int alloc_bootmem_huge_page(struct hstate *h, int nid)
> >  	__attribute__ ((weak, alias("__alloc_bootmem_huge_page")));
> > -int __alloc_bootmem_huge_page(struct hstate *h)
> > +int __alloc_bootmem_huge_page(struct hstate *h, int nid)
> >  {
> >  	struct huge_bootmem_page *m;
> >  	int nr_nodes, node;
> >  
> > +	if (nid >= nr_online_nodes)
> > +		return 0;
> > +	/* do node specific alloc */
> > +	if (nid != NUMA_NO_NODE) {
> > +		m = memblock_alloc_try_nid_raw(huge_page_size(h), huge_page_size(h),
> > +				0, MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> > +		if (m)
> > +			goto found;
> > +		else
> > +			return 0;
> > +	}
> > +	/* do all node balanced alloc */
> >  	for_each_node_mask_to_alloc(h, nr_nodes, node, &node_states[N_MEMORY]) {
> > -		void *addr;
> > -
> > -		addr = memblock_alloc_try_nid_raw(
> > +		m = memblock_alloc_try_nid_raw(
> >  				huge_page_size(h), huge_page_size(h),
> >  				0, MEMBLOCK_ALLOC_ACCESSIBLE, node);
> > -		if (addr) {
> > -			/*
> > -			 * Use the beginning of the huge page to store the
> > -			 * huge_bootmem_page struct (until gather_bootmem
> > -			 * puts them into the mem_map).
> > -			 */
> > -			m = addr;
> > +		/*
> > +		 * Use the beginning of the huge page to store the
> > +		 * huge_bootmem_page struct (until gather_bootmem
> > +		 * puts them into the mem_map).
> > +		 */
> > +		if (m)
> >  			goto found;
> > -		}
> > +		else
> > +			return 0;
> >  	}
> > -	return 0;
> >  
> >  found:
> > -	BUG_ON(!IS_ALIGNED(virt_to_phys(m), huge_page_size(h)));
> >  	/* Put them into a private list first because mem_map is not up yet */
> >  	INIT_LIST_HEAD(&m->list);
> >  	list_add(&m->list, &huge_boot_pages);
> 
> This hunk causes a clang warning now:
> 
> mm/hugetlb.c:2957:33: error: variable 'm' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
>         for_each_node_mask_to_alloc(h, nr_nodes, node, &node_states[N_MEMORY]) {
>         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> mm/hugetlb.c:1254:3: note: expanded from macro 'for_each_node_mask_to_alloc'
>                 nr_nodes > 0 &&                                         \
>                 ^~~~~~~~~~~~
> mm/hugetlb.c:2974:18: note: uninitialized use occurs here
>         INIT_LIST_HEAD(&m->list);
>                         ^
> mm/hugetlb.c:2957:33: note: remove the '&&' if its condition is always true
>         for_each_node_mask_to_alloc(h, nr_nodes, node, &node_states[N_MEMORY]) {
>                                        ^
> mm/hugetlb.c:2942:29: note: initialize the variable 'm' to silence this warning
>         struct huge_bootmem_page *m;
>                                    ^
>                                     = NULL
> 1 error generated.
> 
> I am not sure if it is possible for nr_nodes to be 0 right out of the
> gate so might be a false positive?

With nr_nodes == 0 there will be no memory in the system :)

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2021-09-29 22:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 10:41 [PATCH v7] hugetlbfs: Extend the definition of hugepages parameter to support node allocation Zhenguo Yao
2021-09-28 16:47 ` Mike Rapoport
2021-09-29  5:38   ` Zhenguo Yao
2021-09-29  5:38     ` Zhenguo Yao
2021-09-29 19:24 ` Nathan Chancellor
2021-09-29 22:27   ` Mike Rapoport [this message]
2021-09-29 23:25     ` Andrew Morton
2021-10-01 22:33 ` Mike Kravetz
2021-10-04 15:06   ` Zhenguo Yao
2021-10-04 15:06     ` Zhenguo Yao
2021-10-04 17:34     ` Mike Kravetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YVToRpjbg5mO0bru@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=mike.kravetz@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=paulus@samba.org \
    --cc=willy@infradead.org \
    --cc=yaozhenguo1@gmail.com \
    --cc=yaozhenguo@jd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.