All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: Roman Gushchin <guro@fb.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: RE: [PATCH] mm/hugetlb: avoid hardcoding while checking if cma is reserved
Date: Mon, 6 Jul 2020 22:14:10 +0000	[thread overview]
Message-ID: <B926444035E5E2439431908E3842AFD25596AE@DGGEMI525-MBS.china.huawei.com> (raw)
In-Reply-To: <20200706214808.GB152560@carbon.lan>



> -----Original Message-----
> From: Roman Gushchin [mailto:guro@fb.com]
> Sent: Tuesday, July 7, 2020 9:48 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: akpm@linux-foundation.org; linux-mm@kvack.org;
> linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Mike
> Kravetz <mike.kravetz@oracle.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>
> Subject: Re: [PATCH] mm/hugetlb: avoid hardcoding while checking if cma is
> reserved
> 
> On Mon, Jul 06, 2020 at 08:44:05PM +1200, Barry Song wrote:
> 
> Hello, Barry!
> 
> > hugetlb_cma[0] can be NULL due to various reasons, for example, node0 has
> > no memory. Thus, NULL hugetlb_cma[0] doesn't necessarily mean cma is not
> > enabled. gigantic pages might have been reserved on other nodes.
> 
> Just curious, is it a real-life problem you've seen? If so, I wonder how
> you're using the hugetlb_cma option, and what's the outcome?

Yes. It is kind of stupid but I once got a board on which node0 has no DDR
though node1 and node3 have memory.

I actually prefer we get cma size of per node by:
cma size of one node = hugetlb_cma/ (nodes with memory)
rather than:
cma size of one node = hugetlb_cma/ (all online nodes)

but unfortunately, or the N_MEMORY infrastructures are not ready yet. I mean:

for_each_node_state(nid, N_MEMORY) {
		int res;

		size = min(per_node, hugetlb_cma_size - reserved);
		size = round_up(size, PAGE_SIZE << order);

		res = cma_declare_contiguous_nid(0, size, 0, PAGE_SIZE << order,
						 0, false, "hugetlb",
						 &hugetlb_cma[nid], nid);
		...
	}

> 
> >
> > Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> using cma")
> > Cc: Roman Gushchin <guro@fb.com>
> > Cc: Mike Kravetz <mike.kravetz@oracle.com>
> > Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
> > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > ---
> >  mm/hugetlb.c | 18 +++++++++++++++---
> >  1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 57ece74e3aae..603aa854aa89 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -2571,9 +2571,21 @@ static void __init
> hugetlb_hstate_alloc_pages(struct hstate *h)
> >
> >  	for (i = 0; i < h->max_huge_pages; ++i) {
> >  		if (hstate_is_gigantic(h)) {
> > -			if (IS_ENABLED(CONFIG_CMA) && hugetlb_cma[0]) {
> > -				pr_warn_once("HugeTLB: hugetlb_cma is enabled, skip
> boot time allocation\n");
> > -				break;
> > +			if (IS_ENABLED(CONFIG_CMA)) {
> > +				int nid;
> > +				bool cma_reserved = false;
> > +
> > +				for_each_node_state(nid, N_ONLINE) {
> > +					if (hugetlb_cma[nid]) {
> > +						pr_warn_once("HugeTLB: hugetlb_cma is
> reserved,"
> > +								"skip boot time allocation\n");
> > +						cma_reserved = true;
> > +						break;
> > +					}
> > +				}
> > +
> > +				if (cma_reserved)
> > +					break;
> 
> It's a valid problem, and I like to see it fixed. But I wonder if it would be better
> to introduce a new helper bool hugetlb_cma_enabled()? And move both
> IS_ENABLED(CONFIG_CMA)
> and hugetlb_cma[nid] checks there?

Yep. that would be more readable.

> 
> Thank you!

Thanks
Barry


  reply	other threads:[~2020-07-06 22:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06  8:44 [PATCH] mm/hugetlb: avoid hardcoding while checking if cma is reserved Barry Song
2020-07-06 21:48 ` Roman Gushchin
2020-07-06 22:14   ` Song Bao Hua (Barry Song) [this message]
2020-07-06 22:30   ` Song Bao Hua (Barry Song)
2020-07-06 23:26     ` Roman Gushchin

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=B926444035E5E2439431908E3842AFD25596AE@DGGEMI525-MBS.china.huawei.com \
    --to=song.bao.hua@hisilicon.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --cc=mike.kravetz@oracle.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.