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 2/6] mm: hugetlb: add a new parameter for some functions
Date: Fri, 2 Dec 2016 14:52:30 +0100 [thread overview]
Message-ID: <20161202135229.GJ6830@dhcp22.suse.cz> (raw)
In-Reply-To: <1479107259-2011-3-git-send-email-shijie.huang@arm.com>
On Mon 14-11-16 15:07:35, Huang Shijie wrote:
> This patch adds a new parameter, the "no_init", for these functions:
> alloc_fresh_gigantic_page_node()
> alloc_fresh_gigantic_page()
>
> The prep_new_huge_page() does some initialization for the new page.
> But sometime, we do not need it to do so, such as in the surplus case
> in later patch.
>
> With this parameter, the prep_new_huge_page() can be called by needed:
> If the "no_init" is false, calls the prep_new_huge_page() in
> the alloc_fresh_gigantic_page_node();
This double negative just makes my head spin. I haven't got to later
patch to understand the motivation but if anything bool do_prep would
be much more clear. In general doing these "init if a parameter is
specified" is a bad idea. It just makes the code more convoluted and
sutble. If you need the separation then __foo vs foo with the first
doing the real work and the later some additional initialization on top
sounds like a better idea to me.
Let's see what other changes are about.
> This patch makes preparation for the later patches.
>
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> ---
> mm/hugetlb.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 496b703..db0177b 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1127,27 +1127,29 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
> static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
> static void prep_compound_gigantic_page(struct page *page, unsigned int order);
>
> -static struct page *alloc_fresh_gigantic_page_node(struct hstate *h, int nid)
> +static struct page *alloc_fresh_gigantic_page_node(struct hstate *h,
> + int nid, bool no_init)
> {
> struct page *page;
>
> page = alloc_gigantic_page(nid, huge_page_order(h));
> if (page) {
> prep_compound_gigantic_page(page, huge_page_order(h));
> - prep_new_huge_page(h, page, nid);
> + if (!no_init)
> + prep_new_huge_page(h, page, nid);
> }
>
> return page;
> }
>
> static int alloc_fresh_gigantic_page(struct hstate *h,
> - nodemask_t *nodes_allowed)
> + nodemask_t *nodes_allowed, bool no_init)
> {
> struct page *page = NULL;
> int nr_nodes, node;
>
> for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
> - page = alloc_fresh_gigantic_page_node(h, node);
> + page = alloc_fresh_gigantic_page_node(h, node, no_init);
> if (page)
> return 1;
> }
> @@ -1166,7 +1168,7 @@ static inline void free_gigantic_page(struct page *page, unsigned int order) { }
> static inline void destroy_compound_gigantic_page(struct page *page,
> unsigned int order) { }
> static inline int alloc_fresh_gigantic_page(struct hstate *h,
> - nodemask_t *nodes_allowed) { return 0; }
> + nodemask_t *nodes_allowed, bool no_init) { return 0; }
> #endif
>
> static void update_and_free_page(struct hstate *h, struct page *page)
> @@ -2313,7 +2315,8 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> cond_resched();
>
> if (hstate_is_gigantic(h))
> - ret = alloc_fresh_gigantic_page(h, nodes_allowed);
> + ret = alloc_fresh_gigantic_page(h, nodes_allowed,
> + false);
> else
> ret = alloc_fresh_huge_page(h, nodes_allowed);
> spin_lock(&hugetlb_lock);
> --
> 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 13:52 UTC|newest]
Thread overview: 34+ 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 ` [PATCH v2 1/6] mm: hugetlb: rename some allocation functions Huang Shijie
2016-11-28 13:29 ` Vlastimil Babka
2016-11-29 8:53 ` Huang Shijie
2016-11-29 10:44 ` Vlastimil Babka
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-12-02 13:52 ` Michal Hocko [this message]
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-12-02 13:56 ` Michal Hocko
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-15 6:01 ` Aneesh Kumar K.V
2016-11-15 8:20 ` Huang Shijie
2016-11-15 8:52 ` Huang Shijie
2016-11-16 6:53 ` [PATCH V2 fix " Huang Shijie
2016-12-02 13:58 ` Michal Hocko
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-16 6:55 ` [PATCH V2 fix " Huang Shijie
2016-11-28 14:17 ` Vlastimil Babka
2016-11-29 9:03 ` Huang Shijie
2016-11-29 10:50 ` Vlastimil Babka
2016-11-30 3:02 ` Huang Shijie
2016-12-02 14:03 ` Michal Hocko
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 22:44 ` [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs Andrew Morton
2016-11-15 2:36 ` Huang Shijie
2016-11-28 14:20 ` Vlastimil Babka
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-12-02 14:05 ` [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs 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=20161202135229.GJ6830@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=gerald.schaefer@de.ibm.com \
--cc=kaly.xin@arm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nd@arm.com \
--cc=shijie.huang@arm.com \
--cc=steve.capper@arm.com \
--cc=will.deacon@arm.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