linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Li Xinhai <lixinhai.lxh@gmail.com>,
	linux-mm@kvack.org, Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH] mm/hugetlb: try preferred node first when alloc gigantic page from cma
Date: Mon, 31 Aug 2020 14:44:40 -0700	[thread overview]
Message-ID: <640ddf82-26b1-3e38-5245-df481bc0756e@oracle.com> (raw)
In-Reply-To: <20200830140418.605627-1-lixinhai.lxh@gmail.com>

On 8/30/20 7:04 AM, Li Xinhai wrote:
> Since commit cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic
> hugepages using cma"), the gigantic page would be allocated from node
> which is not the preferred node, although there are pages available from
> that node. The reason is that the nid parameter has been ignored in
> alloc_gigantic_page().
> 
> After this patch, the preferred node is tried first before other allowed
> nodes.

Thank you!
This is an issue that needs to be fixed.

> Fixes: cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
> Cc: Roman Gushchin <guro@fb.com>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
> ---
>  mm/hugetlb.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a301c2d672bf..4a28b8853d47 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1256,8 +1256,15 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
>  		struct page *page;
>  		int node;
>  
> +		if (hugetlb_cma[nid]) {
> +			page = cma_alloc(hugetlb_cma[nid], nr_pages,
> +					huge_page_order(h), true);
> +			if (page)
> +				return page;
> +		}
> +

When looking at your changes, I noticed that this code for allocation
from CMA does not take gfp_mask into account.  The 'normal' use case
is to allocate pool pages with something similar to:

echo 16 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

The routine alloc_pool_huge_page will try to interleave pages among nodes:

	...
        gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;

        for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
	...

which will eventually call alloc_gigantic_page.  If __GFP_THISNODE is
set we really do not want to execute the below for loop in alloc_gigantic_page.

I think the convention in the mm code is that only the lowest level
allocation routines should interpret the GFP flags.  We may need to make
an exception here and check for __GFP_THISNODE.

Michal would be the best person to comment and perhaps make a recommendation.

-- 
Mike Kravetz

>  		for_each_node_mask(node, *nodemask) {
> -			if (!hugetlb_cma[node])
> +			if (node == nid || !hugetlb_cma[node])
>  				continue;
>  
>  			page = cma_alloc(hugetlb_cma[node], nr_pages,
> 


  reply	other threads:[~2020-08-31 21:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 14:04 Li Xinhai
2020-08-31 21:44 ` Mike Kravetz [this message]
2020-09-01 13:41   ` Michal Hocko
2020-09-01 14:20     ` Li Xinhai
2020-09-01 14:53       ` Michal Hocko
2020-09-01 14:59         ` Li Xinhai

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=640ddf82-26b1-3e38-5245-df481bc0756e@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=linux-mm@kvack.org \
    --cc=lixinhai.lxh@gmail.com \
    --cc=mhocko@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox