All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Paul Mundt <lethal@linux-sh.org>,
	Nish Aravamudan <nish.aravamudan@gmail.com>,
	Adrian Bunk <bunk@kernel.org>,
	wli@holomorphy.com, linux-sh@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: HugeTLB vs. SH3 cpu
Date: Wed, 02 Apr 2008 22:55:56 +0000	[thread overview]
Message-ID: <20080402225556.GI21524@us.ibm.com> (raw)
In-Reply-To: <20080402080448.GA4171@linux-sh.org>

On 02.04.2008 [17:04:48 +0900], Paul Mundt wrote:
> On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> > > fs/Kconfig says:
> > >
> > >  config HUGETLBFS
> > >         bool "HugeTLB file system support"
> > >         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > >
> > >
> > >  arch/sh/mm/Kconfig says:
> > >
> > >  choice
> > >         prompt "HugeTLB page size"
> > >         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU
> > 
> > So the problem is that SH3 is allowed to enable
> > HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
> > due to some #ifdeffery on the hugepage size. So either the choice
> > needs to be extended to include CPU_SH3 (which builds here, when
> > changed) or the HUGETLBFS conditional needs to depend more
> > specifically on SH4/5 and not just SUPERH. I think the arch maintainer
> > has to make that call, as I don't know the hardware to say if SH3
> > actually supports multiple hugepage sizes.
> > 
> The problem is that the hugetlb Kconfig stuff is a complete mess. There's
> a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
> depend on each other.
> 
> Sorting out the mess noted by Adrian is pretty trivial with a
> HAVE_HUGETLB_PAGE. How about this?

I'm confused, isn't the following simpler fix equivalent?

Fix sh3 build with HUGETLBFS=y. Only SH4 and SH5 actually support
HUGETLB_PAGE (which HUGETLBFS depends on).

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

diff --git a/fs/Kconfig b/fs/Kconfig
index d731282..1981f8e 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
 
 config HUGETLBFS
 	bool "HugeTLB file system support"
-	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
+	depends on X86 || IA64 || PPC64 || SPARC64 || ((CPU_SH4 || CPU_SH5) && MMU) || BROKEN
 	help
 	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
 	  ramfs. For architectures that support it, say Y here and read

WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Paul Mundt <lethal@linux-sh.org>,
	Nish Aravamudan <nish.aravamudan@gmail.com>,
	Adrian Bunk <bunk@kernel.org>,
	wli@holomorphy.com, linux-sh@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: HugeTLB vs. SH3 cpu
Date: Wed, 2 Apr 2008 15:55:56 -0700	[thread overview]
Message-ID: <20080402225556.GI21524@us.ibm.com> (raw)
In-Reply-To: <20080402080448.GA4171@linux-sh.org>

On 02.04.2008 [17:04:48 +0900], Paul Mundt wrote:
> On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> > > fs/Kconfig says:
> > >
> > >  config HUGETLBFS
> > >         bool "HugeTLB file system support"
> > >         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > >
> > >
> > >  arch/sh/mm/Kconfig says:
> > >
> > >  choice
> > >         prompt "HugeTLB page size"
> > >         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU
> > 
> > So the problem is that SH3 is allowed to enable
> > HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
> > due to some #ifdeffery on the hugepage size. So either the choice
> > needs to be extended to include CPU_SH3 (which builds here, when
> > changed) or the HUGETLBFS conditional needs to depend more
> > specifically on SH4/5 and not just SUPERH. I think the arch maintainer
> > has to make that call, as I don't know the hardware to say if SH3
> > actually supports multiple hugepage sizes.
> > 
> The problem is that the hugetlb Kconfig stuff is a complete mess. There's
> a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
> depend on each other.
> 
> Sorting out the mess noted by Adrian is pretty trivial with a
> HAVE_HUGETLB_PAGE. How about this?

I'm confused, isn't the following simpler fix equivalent?

Fix sh3 build with HUGETLBFS=y. Only SH4 and SH5 actually support
HUGETLB_PAGE (which HUGETLBFS depends on).

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

diff --git a/fs/Kconfig b/fs/Kconfig
index d731282..1981f8e 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
 
 config HUGETLBFS
 	bool "HugeTLB file system support"
-	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
+	depends on X86 || IA64 || PPC64 || SPARC64 || ((CPU_SH4 || CPU_SH5) && MMU) || BROKEN
 	help
 	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
 	  ramfs. For architectures that support it, say Y here and read

  parent reply	other threads:[~2008-04-02 22:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 22:58 HugeTLB vs. SH3 cpu Adrian Bunk
2008-04-01 22:58 ` Adrian Bunk
2008-04-01 23:26 ` Nish Aravamudan
2008-04-01 23:26   ` Nish Aravamudan
2008-04-02  8:04   ` Paul Mundt
2008-04-02  8:04     ` Paul Mundt
2008-04-02 10:15     ` Mel Gorman
2008-04-02 10:15       ` Mel Gorman
2008-04-03  5:52       ` Paul Mundt
2008-04-03  5:52         ` Paul Mundt
2008-04-02 22:55     ` Nishanth Aravamudan [this message]
2008-04-02 22:55       ` Nishanth Aravamudan
2008-04-03  0:06       ` Dave Hansen
2008-04-03  0:06         ` Dave Hansen
2008-04-03  5:48         ` Paul Mundt
2008-04-03  5:48           ` Paul Mundt

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=20080402225556.GI21524@us.ibm.com \
    --to=nacc@us.ibm.com \
    --cc=bunk@kernel.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=nish.aravamudan@gmail.com \
    --cc=wli@holomorphy.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 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.