linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	mtosatti@redhat.com, aarcange@redhat.com, mgorman@suse.de,
	andi@firstfloor.org, davidlohr@hp.com, rientjes@google.com,
	isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
	riel@redhat.com
Subject: Re: [PATCH 4/4] hugetlb: add support for gigantic page allocation at runtime
Date: Tue, 8 Apr 2014 15:51:02 -0700	[thread overview]
Message-ID: <20140408155102.d55e3b798681e316d957f383@linux-foundation.org> (raw)
In-Reply-To: <20140407144935.259d4301@redhat.com>

On Mon, 7 Apr 2014 14:49:35 -0400 Luiz Capitulino <lcapitulino@redhat.com> wrote:

> > > ---
> > >  arch/x86/include/asm/hugetlb.h |  10 +++
> > >  mm/hugetlb.c                   | 177 ++++++++++++++++++++++++++++++++++++++---
> > >  2 files changed, 176 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
> > > index a809121..2b262f7 100644
> > > --- a/arch/x86/include/asm/hugetlb.h
> > > +++ b/arch/x86/include/asm/hugetlb.h
> > > @@ -91,6 +91,16 @@ static inline void arch_release_hugepage(struct page *page)
> > >  {
> > >  }
> > >  
> > > +static inline int arch_prepare_gigantic_page(struct page *page)
> > > +{
> > > +	return 0;
> > > +}
> > > +
> > > +static inline void arch_release_gigantic_page(struct page *page)
> > > +{
> > > +}
> > > +
> > > +
> > >  static inline void arch_clear_hugepage_flags(struct page *page)
> > >  {
> > >  }
> > 
> > These are defined only on arch/x86, but called in generic code.
> > Does it cause build failure on other archs?
> 
> Hmm, probably. The problem here is that I'm unable to test this
> code in other archs. So I think the best solution for the first
> merge is to make the build of this feature conditional to x86_64?
> Then the first person interested in making this work in other
> archs add the generic code. Sounds reasonable?

These functions don't actually do anything so if and when other
architectures come along to implement this feature, their developers
won't know what you were thinking when you added them.  So how about
some code comments to explain their roles and responsibilities?

Or just delete them altogether and let people add them (or something
similar) if and when the need arises.  It's hard to tell when one lacks
telepathic powers, sigh.

--
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>

  parent reply	other threads:[~2014-04-08 22:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02 18:08 [PATCH 0/4] hugetlb: add support " Luiz Capitulino
2014-04-02 18:08 ` [PATCH 1/4] hugetlb: add hstate_is_gigantic() Luiz Capitulino
2014-04-07 17:57   ` Naoya Horiguchi
2014-04-08  2:00   ` Yasuaki Ishimatsu
2014-04-02 18:08 ` [PATCH 2/4] hugetlb: update_and_free_page(): don't clear PG_reserved bit Luiz Capitulino
2014-04-07 17:58   ` Naoya Horiguchi
2014-04-08  2:01   ` Yasuaki Ishimatsu
2014-04-02 18:08 ` [PATCH 3/4] hugetlb: move helpers up in the file Luiz Capitulino
2014-04-07 17:58   ` Naoya Horiguchi
2014-04-08  2:01   ` Yasuaki Ishimatsu
2014-04-02 18:08 ` [PATCH 4/4] hugetlb: add support for gigantic page allocation at runtime Luiz Capitulino
2014-04-04  3:05   ` Yasuaki Ishimatsu
2014-04-04 13:30     ` Luiz Capitulino
2014-04-08  1:58       ` Yasuaki Ishimatsu
2014-04-07 17:58   ` Naoya Horiguchi
     [not found]   ` <1396893509-x52fgnka@n-horiguchi@ah.jp.nec.com>
2014-04-07 18:49     ` Luiz Capitulino
2014-04-07 19:03       ` Naoya Horiguchi
2014-04-08 22:51       ` Andrew Morton [this message]
2014-04-09  0:29         ` Luiz Capitulino
2014-04-03 15:33 ` [PATCH 0/4] hugetlb: add support " Andrea Arcangeli

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=20140408155102.d55e3b798681e316d957f383@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=davidlohr@hp.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mtosatti@redhat.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=yinghai@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