From: mhocko@suse.com (Michal Hocko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 fix 5/6] mm: hugetlb: add a new function to allocate a new gigantic page
Date: Fri, 2 Dec 2016 15:03:30 +0100 [thread overview]
Message-ID: <20161202140325.GM6830@dhcp22.suse.cz> (raw)
In-Reply-To: <1479279304-31379-1-git-send-email-shijie.huang@arm.com>
On Wed 16-11-16 14:55:04, Huang Shijie wrote:
> There are three ways we can allocate a new gigantic page:
>
> 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
> the gigantic page.
>
> 2. The NUMA is enabled, but the vma is NULL.
> There is no memory policy we can refer to.
> So create a @nodes_allowed, initialize it with init_nodemask_of_mempolicy()
> or init_nodemask_of_node(). Then use alloc_fresh_gigantic_page() to get
> the gigantic page.
>
> 3. The NUMA is enabled, and the vma is valid.
> We can follow the memory policy of the @vma.
>
> Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
> to get the gigantic page.
Again __hugetlb_alloc_gigantic_page is not used and it is hard to deduce
its usage from this commit. The above shouldn't be really much different from
what we do in alloc_pages_vma so please make sure to check it before
coming up with something hugetlb specific.
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> ---
> Since the huge_nodemask() is changed, we have to change this function a little.
>
> ---
> mm/hugetlb.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6995087..c33bddc 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1502,6 +1502,69 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
>
> /*
> * There are 3 ways this can get called:
> + *
> + * 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
> + * the gigantic page.
> + *
> + * 2. The NUMA is enabled, but the vma is NULL.
> + * Create a @nodes_allowed, and use alloc_fresh_gigantic_page() to get
> + * the gigantic page.
> + *
> + * 3. The NUMA is enabled, and the vma is valid.
> + * Use the @vma's memory policy.
> + * Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
> + * to get the gigantic page.
> + */
> +static struct page *__hugetlb_alloc_gigantic_page(struct hstate *h,
> + struct vm_area_struct *vma, unsigned long addr, int nid)
> +{
> + NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
> + struct page *page = NULL;
> +
> + /* Not NUMA */
> + if (!IS_ENABLED(CONFIG_NUMA)) {
> + if (nid == NUMA_NO_NODE)
> + nid = numa_mem_id();
> +
> + page = alloc_gigantic_page(nid, huge_page_order(h));
> + if (page)
> + prep_compound_gigantic_page(page, huge_page_order(h));
> +
> + NODEMASK_FREE(nodes_allowed);
> + return page;
> + }
> +
> + /* NUMA && !vma */
> + if (!vma) {
> + if (nid == NUMA_NO_NODE) {
> + if (!init_nodemask_of_mempolicy(nodes_allowed)) {
> + NODEMASK_FREE(nodes_allowed);
> + nodes_allowed = &node_states[N_MEMORY];
> + }
> + } else if (nodes_allowed) {
> + init_nodemask_of_node(nodes_allowed, nid);
> + } else {
> + nodes_allowed = &node_states[N_MEMORY];
> + }
> +
> + page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
> +
> + if (nodes_allowed != &node_states[N_MEMORY])
> + NODEMASK_FREE(nodes_allowed);
> +
> + return page;
> + }
> +
> + /* NUMA && vma */
> + if (huge_nodemask(vma, addr, nodes_allowed))
> + page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
> +
> + NODEMASK_FREE(nodes_allowed);
> + return page;
> +}
> +
> +/*
> + * There are 3 ways this can get called:
> * 1. With vma+addr: we use the VMA's memory policy
> * 2. With !vma, but nid=NUMA_NO_NODE: We try to allocate a huge
> * page from any node, and let the buddy allocator itself figure
> --
> 2.5.5
>
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com>
To: Huang Shijie <shijie.huang@arm.com>
Cc: akpm@linux-foundation.org, catalin.marinas@arm.com,
n-horiguchi@ah.jp.nec.com, kirill.shutemov@linux.intel.com,
aneesh.kumar@linux.vnet.ibm.com, gerald.schaefer@de.ibm.com,
mike.kravetz@oracle.com, linux-mm@kvack.org, will.deacon@arm.com,
steve.capper@arm.com, kaly.xin@arm.com, nd@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V2 fix 5/6] mm: hugetlb: add a new function to allocate a new gigantic page
Date: Fri, 2 Dec 2016 15:03:30 +0100 [thread overview]
Message-ID: <20161202140325.GM6830@dhcp22.suse.cz> (raw)
In-Reply-To: <1479279304-31379-1-git-send-email-shijie.huang@arm.com>
On Wed 16-11-16 14:55:04, Huang Shijie wrote:
> There are three ways we can allocate a new gigantic page:
>
> 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
> the gigantic page.
>
> 2. The NUMA is enabled, but the vma is NULL.
> There is no memory policy we can refer to.
> So create a @nodes_allowed, initialize it with init_nodemask_of_mempolicy()
> or init_nodemask_of_node(). Then use alloc_fresh_gigantic_page() to get
> the gigantic page.
>
> 3. The NUMA is enabled, and the vma is valid.
> We can follow the memory policy of the @vma.
>
> Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
> to get the gigantic page.
Again __hugetlb_alloc_gigantic_page is not used and it is hard to deduce
its usage from this commit. The above shouldn't be really much different from
what we do in alloc_pages_vma so please make sure to check it before
coming up with something hugetlb specific.
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> ---
> Since the huge_nodemask() is changed, we have to change this function a little.
>
> ---
> mm/hugetlb.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6995087..c33bddc 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1502,6 +1502,69 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
>
> /*
> * There are 3 ways this can get called:
> + *
> + * 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
> + * the gigantic page.
> + *
> + * 2. The NUMA is enabled, but the vma is NULL.
> + * Create a @nodes_allowed, and use alloc_fresh_gigantic_page() to get
> + * the gigantic page.
> + *
> + * 3. The NUMA is enabled, and the vma is valid.
> + * Use the @vma's memory policy.
> + * Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
> + * to get the gigantic page.
> + */
> +static struct page *__hugetlb_alloc_gigantic_page(struct hstate *h,
> + struct vm_area_struct *vma, unsigned long addr, int nid)
> +{
> + NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
> + struct page *page = NULL;
> +
> + /* Not NUMA */
> + if (!IS_ENABLED(CONFIG_NUMA)) {
> + if (nid == NUMA_NO_NODE)
> + nid = numa_mem_id();
> +
> + page = alloc_gigantic_page(nid, huge_page_order(h));
> + if (page)
> + prep_compound_gigantic_page(page, huge_page_order(h));
> +
> + NODEMASK_FREE(nodes_allowed);
> + return page;
> + }
> +
> + /* NUMA && !vma */
> + if (!vma) {
> + if (nid == NUMA_NO_NODE) {
> + if (!init_nodemask_of_mempolicy(nodes_allowed)) {
> + NODEMASK_FREE(nodes_allowed);
> + nodes_allowed = &node_states[N_MEMORY];
> + }
> + } else if (nodes_allowed) {
> + init_nodemask_of_node(nodes_allowed, nid);
> + } else {
> + nodes_allowed = &node_states[N_MEMORY];
> + }
> +
> + page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
> +
> + if (nodes_allowed != &node_states[N_MEMORY])
> + NODEMASK_FREE(nodes_allowed);
> +
> + return page;
> + }
> +
> + /* NUMA && vma */
> + if (huge_nodemask(vma, addr, nodes_allowed))
> + page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
> +
> + NODEMASK_FREE(nodes_allowed);
> + return page;
> +}
> +
> +/*
> + * There are 3 ways this can get called:
> * 1. With vma+addr: we use the VMA's memory policy
> * 2. With !vma, but nid=NUMA_NO_NODE: We try to allocate a huge
> * page from any node, and let the buddy allocator itself figure
> --
> 2.5.5
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-12-02 14:03 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 7:07 [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 1/6] mm: hugetlb: rename some allocation functions Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-11-28 13:29 ` Vlastimil Babka
2016-11-28 13:29 ` Vlastimil Babka
2016-11-29 8:53 ` Huang Shijie
2016-11-29 8:53 ` Huang Shijie
2016-11-29 10:44 ` Vlastimil Babka
2016-11-29 10:44 ` Vlastimil Babka
2016-11-30 3:03 ` Huang Shijie
2016-11-30 3:03 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 2/6] mm: hugetlb: add a new parameter for some functions Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-12-02 13:52 ` Michal Hocko
2016-12-02 13:52 ` Michal Hocko
2016-12-05 3:05 ` Huang Shijie
2016-12-05 3:05 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 3/6] mm: hugetlb: change the return type for alloc_fresh_gigantic_page Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-12-02 13:56 ` Michal Hocko
2016-12-02 13:56 ` Michal Hocko
2016-12-05 3:06 ` Huang Shijie
2016-12-05 3:06 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 4/6] mm: mempolicy: intruduce a helper huge_nodemask() Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-11-15 6:01 ` Aneesh Kumar K.V
2016-11-15 6:01 ` Aneesh Kumar K.V
2016-11-15 8:20 ` Huang Shijie
2016-11-15 8:20 ` Huang Shijie
2016-11-15 8:52 ` Huang Shijie
2016-11-15 8:52 ` Huang Shijie
2016-11-16 6:53 ` [PATCH V2 fix " Huang Shijie
2016-11-16 6:53 ` Huang Shijie
2016-12-02 13:58 ` Michal Hocko
2016-12-02 13:58 ` Michal Hocko
2016-12-05 3:09 ` Huang Shijie
2016-12-05 3:09 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 5/6] mm: hugetlb: add a new function to allocate a new gigantic page Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-11-16 6:55 ` [PATCH V2 fix " Huang Shijie
2016-11-16 6:55 ` Huang Shijie
2016-11-28 14:17 ` Vlastimil Babka
2016-11-28 14:17 ` Vlastimil Babka
2016-11-29 9:03 ` Huang Shijie
2016-11-29 9:03 ` Huang Shijie
2016-11-29 10:50 ` Vlastimil Babka
2016-11-29 10:50 ` Vlastimil Babka
2016-11-30 3:02 ` Huang Shijie
2016-11-30 3:02 ` Huang Shijie
2016-12-02 14:03 ` Michal Hocko [this message]
2016-12-02 14:03 ` Michal Hocko
2016-12-05 3:15 ` Huang Shijie
2016-12-05 3:15 ` Huang Shijie
2016-11-14 7:07 ` [PATCH v2 6/6] mm: hugetlb: support gigantic surplus pages Huang Shijie
2016-11-14 7:07 ` Huang Shijie
2016-11-14 22:44 ` [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs Andrew Morton
2016-11-14 22:44 ` Andrew Morton
2016-11-15 2:36 ` Huang Shijie
2016-11-15 2:36 ` Huang Shijie
2016-11-28 14:20 ` Vlastimil Babka
2016-11-28 14:20 ` Vlastimil Babka
2016-11-29 9:07 ` Huang Shijie
2016-11-29 9:07 ` Huang Shijie
2016-11-30 6:30 ` [PATCH extra ] mm: hugetlb: add description for alloc_gigantic_page() Huang Shijie
2016-11-30 6:30 ` Huang Shijie
2016-12-02 14:05 ` [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs Michal Hocko
2016-12-02 14:05 ` Michal Hocko
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=20161202140325.GM6830@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=linux-arm-kernel@lists.infradead.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 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.