From: Michal Hocko <mhocko@suse.com>
To: Li Xinhai <lixinhai.lxh@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
Roman Gushchin <guro@fb.com>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma
Date: Wed, 2 Sep 2020 08:14:25 +0200 [thread overview]
Message-ID: <20200902061425.GB6363@dhcp22.suse.cz> (raw)
In-Reply-To: <20200902025016.697260-1-lixinhai.lxh@gmail.com>
On Wed 02-09-20 10:50:16, 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().
>
> Besides, the __GFP_THISNODE also need be checked if user required to
> alloc only from the preferred node.
>
> After this patch, the preferred node is tried first before other allowed
> nodes, and don't try to allocate from other nodes if __GFP_THISNODE is
> specified. If user don't specify the preferred node, the current node
> will be used as preferred node, which makes sure consistent behavior of
> allocating gigantic and non-gigantic hugetlb page.
Technically speaking this is still not in full sync with the allocator
semantic. E.g. cma allocator should try nodes in the node distance
order. Possible but not sure how much we really do care for those who
preallocate cma pools. Also __GFP_NOWAIT should skip CMA as that
requires mutex - or even better make alloc_cma gfp aware. Likely few
more things.
If we care then something for a patch or two on its own and also make
the cma part a function on its own to remove the ugly ifdef.
> 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>
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> v2->V3
> Consider current node as preferred node if nid is NUMA_NO_NODE, thanks
> Mike.
>
> v1->v2:
> With review by Mike and Michal, need to check __GFP_THISNODE to avoid
> allocate from other nodes.
>
> mm/hugetlb.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a301c2d672bf..5957dc80ebb1 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1250,21 +1250,32 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
> int nid, nodemask_t *nodemask)
> {
> unsigned long nr_pages = 1UL << huge_page_order(h);
> + if (nid == NUMA_NO_NODE)
> + nid = numa_mem_id();
>
> #ifdef CONFIG_CMA
> {
> struct page *page;
> int node;
>
> - for_each_node_mask(node, *nodemask) {
> - if (!hugetlb_cma[node])
> - continue;
> -
> - page = cma_alloc(hugetlb_cma[node], nr_pages,
> - huge_page_order(h), true);
> + if (hugetlb_cma[nid]) {
> + page = cma_alloc(hugetlb_cma[nid], nr_pages,
> + huge_page_order(h), true);
> if (page)
> return page;
> }
> +
> + if (!(gfp_mask & __GFP_THISNODE)) {
> + for_each_node_mask(node, *nodemask) {
> + if (node == nid || !hugetlb_cma[node])
> + continue;
> +
> + page = cma_alloc(hugetlb_cma[node], nr_pages,
> + huge_page_order(h), true);
> + if (page)
> + return page;
> + }
> + }
> }
> #endif
>
> --
> 2.18.4
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-09-02 6:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-02 2:50 Li Xinhai
2020-09-02 6:14 ` Michal Hocko [this message]
2020-09-02 18:07 ` 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=20200902061425.GB6363@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox