From: "Du, Changbin" <changbin.du@intel.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: changbin.du@intel.com, akpm@linux-foundation.org, corbet@lwn.net,
hughd@google.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm, thp: introduce dedicated transparent huge page allocation interfaces
Date: Tue, 17 Oct 2017 17:16:39 +0800 [thread overview]
Message-ID: <20171017091638.GA7748@intel.com> (raw)
In-Reply-To: <66a3f340-ff44-efad-48ad-a95554938a29@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5502 bytes --]
Hi Khandual,
Thanks for your review.
On Tue, Oct 17, 2017 at 01:38:07PM +0530, Anshuman Khandual wrote:
> On 10/16/2017 02:49 PM, changbin.du@intel.com wrote:
> > From: Changbin Du <changbin.du@intel.com>
> >
> > This patch introduced 4 new interfaces to allocate a prepared
> > transparent huge page.
> > - alloc_transhuge_page_vma
> > - alloc_transhuge_page_nodemask
> > - alloc_transhuge_page_node
> > - alloc_transhuge_page
> >
>
> If we are trying to match HugeTLB helpers, then it should have
> format something like alloc_transhugepage_xxx instead of
> alloc_transhuge_page_XXX. But I think its okay.
>
HugeTLB helpers are something like alloc_huge_page, so I think
alloc_transhuge_page match it. And existing names already have
*transhuge_page* style.
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index 14bc21c..1dd2c33 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -130,9 +130,20 @@ extern unsigned long thp_get_unmapped_area(struct file *filp,
> > unsigned long addr, unsigned long len, unsigned long pgoff,
> > unsigned long flags);
> >
> > -extern void prep_transhuge_page(struct page *page);
> > extern void free_transhuge_page(struct page *page);
> >
> > +struct page *alloc_transhuge_page_vma(gfp_t gfp_mask,
> > + struct vm_area_struct *vma, unsigned long addr);
> > +struct page *alloc_transhuge_page_nodemask(gfp_t gfp_mask,
> > + int preferred_nid, nodemask_t *nmask);
>
> Would not they require 'extern' here ?
>
Need or not, function declaration are implicitly 'extern'. I will add it to
align with existing code.
> > +
> > +static inline struct page *alloc_transhuge_page_node(int nid, gfp_t gfp_mask)
> > +{
> > + return alloc_transhuge_page_nodemask(gfp_mask, nid, NULL);
> > +}
> > +
> > +struct page *alloc_transhuge_page(gfp_t gfp_mask);
> > +
> > bool can_split_huge_page(struct page *page, int *pextra_pins);
> > int split_huge_page_to_list(struct page *page, struct list_head *list);
> > static inline int split_huge_page(struct page *page)
> > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > index 643c7ae..70a00f3 100644
> > --- a/include/linux/migrate.h
> > +++ b/include/linux/migrate.h
> > @@ -42,19 +42,15 @@ static inline struct page *new_page_nodemask(struct page *page,
> > return alloc_huge_page_nodemask(page_hstate(compound_head(page)),
> > preferred_nid, nodemask);
> >
> > - if (thp_migration_supported() && PageTransHuge(page)) {
> > - order = HPAGE_PMD_ORDER;
> > - gfp_mask |= GFP_TRANSHUGE;
> > - }
> > -
> > if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
> > gfp_mask |= __GFP_HIGHMEM;
> >
> > - new_page = __alloc_pages_nodemask(gfp_mask, order,
> > + if (thp_migration_supported() && PageTransHuge(page))
> > + return alloc_transhuge_page_nodemask(gfp_mask | GFP_TRANSHUGE,
> > + preferred_nid, nodemask);
> > + else
> > + return __alloc_pages_nodemask(gfp_mask, order,
> > preferred_nid, nodemask);
> > -
> > - if (new_page && PageTransHuge(page))
> > - prep_transhuge_page(new_page);
>
> This makes sense, calling prep_transhuge_page() inside the
> function alloc_transhuge_page_nodemask() is better I guess.
>
> >
> > return new_page;
> > }
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 269b5df..e267488 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -490,7 +490,7 @@ static inline struct list_head *page_deferred_list(struct page *page)
> > return (struct list_head *)&page[2].mapping;
> > }
> >
> > -void prep_transhuge_page(struct page *page)
> > +static void prep_transhuge_page(struct page *page)
>
> Right. It wont be used outside huge page allocation context and
> you have already mentioned about it.
>
> > {
> > /*
> > * we use page->mapping and page->indexlru in second tail page
> > @@ -501,6 +501,45 @@ void prep_transhuge_page(struct page *page)
> > set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
> > }
> >
> > +struct page *alloc_transhuge_page_vma(gfp_t gfp_mask,
> > + struct vm_area_struct *vma, unsigned long addr)
> > +{
> > + struct page *page;
> > +
> > + page = alloc_pages_vma(gfp_mask | __GFP_COMP, HPAGE_PMD_ORDER,
> > + vma, addr, numa_node_id(), true);
> > + if (unlikely(!page))
> > + return NULL;
> > + prep_transhuge_page(page);
> > + return page;
> > +}
>
> __GFP_COMP and HPAGE_PMD_ORDER are the minimum flags which will be used
> for huge page allocation and preparation. Any thing else depending upon
> the context will be passed by the caller. Makes sense.
>
yes, thanks.
> > +
> > +struct page *alloc_transhuge_page_nodemask(gfp_t gfp_mask,
> > + int preferred_nid, nodemask_t *nmask)
> > +{
> > + struct page *page;
> > +
> > + page = __alloc_pages_nodemask(gfp_mask | __GFP_COMP, HPAGE_PMD_ORDER,
> > + preferred_nid, nmask);
> > + if (unlikely(!page))
> > + return NULL;
> > + prep_transhuge_page(page);
> > + return page;
> > +}
> > +
>
> Same here.
>
> > +struct page *alloc_transhuge_page(gfp_t gfp_mask)
> > +{
> > + struct page *page;
> > +
> > + VM_BUG_ON(!(gfp_mask & __GFP_COMP));
>
> You expect the caller to provide __GFP_COMP, why ? You are
> anyways providing it later.
>
oops, I forgot to update this line. Will remove it. Thanks for figuring it out.
--
Thanks,
Changbin Du
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2017-10-17 9:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 9:19 [PATCH 0/2] mm, thp: introduce dedicated transparent huge page allocation interfaces changbin.du
2017-10-16 9:19 ` changbin.du
2017-10-16 9:19 ` [PATCH 1/2] " changbin.du
2017-10-16 9:19 ` changbin.du
2017-10-17 8:08 ` Anshuman Khandual
2017-10-17 8:08 ` Anshuman Khandual
2017-10-17 9:16 ` Du, Changbin [this message]
2017-10-17 10:20 ` Michal Hocko
2017-10-17 10:20 ` Michal Hocko
2017-10-17 10:22 ` Michal Hocko
2017-10-17 10:22 ` Michal Hocko
2017-10-18 11:00 ` Du, Changbin
2017-10-19 12:49 ` Michal Hocko
2017-10-19 12:49 ` Michal Hocko
2017-10-20 8:31 ` Du, Changbin
2017-10-17 11:12 ` Kirill A. Shutemov
2017-10-17 11:12 ` Kirill A. Shutemov
2017-10-18 11:01 ` Du, Changbin
2017-10-18 15:54 ` kbuild test robot
2017-10-18 15:54 ` kbuild test robot
2017-10-18 16:01 ` kbuild test robot
2017-10-18 16:01 ` kbuild test robot
2017-10-16 9:19 ` [PATCH 2/2] mm: rename page dtor functions to {compound,huge,transhuge}_page__dtor changbin.du
2017-10-16 9:19 ` changbin.du
2017-10-17 8:36 ` Anshuman Khandual
2017-10-17 8:36 ` Anshuman Khandual
2017-10-17 9:21 ` Du, Changbin
2017-10-17 10:22 ` Michal Hocko
2017-10-17 10:22 ` Michal Hocko
2017-10-17 11:22 ` Kirill A. Shutemov
2017-10-17 11:22 ` Kirill A. Shutemov
2017-10-17 12:00 ` Michal Hocko
2017-10-17 12:00 ` Michal Hocko
2017-10-17 23:28 ` [PATCH 0/2] mm, thp: introduce dedicated transparent huge page allocation interfaces Andrew Morton
2017-10-17 23:28 ` Andrew Morton
2017-10-18 11:02 ` Du, Changbin
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=20171017091638.GA7748@intel.com \
--to=changbin.du@intel.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=hughd@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.