From: "Du, Changbin" <changbin.du@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: changbin.du@intel.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] mm, thp: introduce generic transparent huge page allocation interfaces
Date: Sat, 9 Dec 2017 11:26:58 +0800 [thread overview]
Message-ID: <20171209032658.koktsag3hqpm7psx@intel.com> (raw)
In-Reply-To: <20171208082737.GA15790@dhcp22.suse.cz>
On Fri, Dec 08, 2017 at 09:27:37AM +0100, Michal Hocko wrote:
> On Fri 08-12-17 12:42:55, 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. These interfaces merge distributed two-step allocation as simple
> > single step. And they can avoid issue like forget to call prep_transhuge_page()
> > or call it on wrong page. A real fix:
> > 40a899e ("mm: migrate: fix an incorrect call of prep_transhuge_page()")
> >
> > Anyway, I just want to prove that expose direct allocation interfaces is
> > better than a interface only do the second part of it.
> >
> > These are similar to alloc_hugepage_xxx which are for hugetlbfs pages. New
> > interfaces are:
> > - alloc_transhuge_page_vma
> > - alloc_transhuge_page_nodemask
> > - alloc_transhuge_page_node
> > - alloc_transhuge_page
> >
> > These interfaces implicitly add __GFP_COMP gfp mask which is the minimum
> > flags used for huge page allocation. More flags leave to the callers.
> >
> > This patch does below changes:
> > - define alloc_transhuge_page_xxx interfaces
> > - apply them to all existing code
> > - declare prep_transhuge_page as static since no others use it
> > - remove alloc_hugepage_vma definition since it no longer has users
>
> I am not really convinced this is a huge win, to be honest. Just look at
> the diffstat. Very few callsites get marginally simpler while we add a
> lot of stubs and the code churn.
>
I know we should write less code, but it is not the only rule. Sometimes we need
add little more code since the compiler requires so, but it doesn't mean then
the compiler will generate worse/more machine code. Besides this, I really want
to know wethere any other considerations you have. Thanks.
> > mm/mempolicy.c | 14 +++-----------
> > mm/migrate.c | 14 ++++----------
> > mm/shmem.c | 6 ++----
> > 8 files changed, 90 insertions(+), 56 deletions(-)
> --
> Michal Hocko
> SUSE Labs
--
Thanks,
Changbin Du
--
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:[~2017-12-09 3:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 4:42 changbin.du
2017-12-08 8:27 ` Michal Hocko
2017-12-09 3:26 ` Du, Changbin [this message]
2017-12-10 9:55 ` 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=20171209032658.koktsag3hqpm7psx@intel.com \
--to=changbin.du@intel.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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