On (02/04/08 17:04), Paul Mundt didst pronounce:
quoted text > 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.
>
I believe the original intention was that HUGETLB_PAGE would build the
hugepage pool and the arch-specific code and HUGETLBFS would be the userspace
interface but not necessarily the only one. Whatever the original intention,
it's no longer the case as they have become inter-dependant. Fixing it is
not straight-forward but I don't think we want to collapse HUGETLB_PAGE and
HUGETLBFS just yet either.
quoted text > Sorting out the mess noted by Adrian is pretty trivial with a
> HAVE_HUGETLB_PAGE. How about this?
>
While I am loathe to add yet more hugetlb-related Kconfig options, this
does seem to be the common way of dealing with features that depend on the
architecture (e.g. HAVE_OPROFILE, HAVE_IDE, HAVE_KPROBES etc.).
quoted text > Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>
It appears to be doing the right thing making defconfig across the different
architectures.
Acked-by: Mel Gorman <mel@csn.ul.ie>
quoted text > ---
>
> arch/ia64/Kconfig | 1 +
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> arch/sh/Kconfig | 2 ++
> arch/sparc64/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> fs/Kconfig | 3 ++-
> mm/Kconfig | 3 +++
> 7 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 8fa3faf..bb1e02b 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -19,6 +19,7 @@ config IA64
> select HAVE_OPROFILE
> select HAVE_KPROBES
> select HAVE_KRETPROBES
> + select HAVE_HUGETLB_PAGE
> default y
> help
> The Itanium Processor Family is Intel's 64-bit successor to
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 0c3face..7c937ad 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -1,5 +1,6 @@
> config PPC64
> bool "64-bit kernel"
> + select HAVE_HUGETLB_PAGE
> default n
> help
> This option selects whether a 32-bit or a 64-bit kernel
hmm... This is what Kconfig is currently doing but by rights, it should be
set on a per-processor basis. I guess it's outside the scope of this patch as
there isn't an obvious way to tell what processor versions support huge pages.
quoted text > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index df2e2f9..c48f629 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -114,6 +114,7 @@ config CPU_SH3
>
> config CPU_SH4
> bool
> + select HAVE_HUGETLB_PAGE
> select CPU_HAS_INTEVT
> select CPU_HAS_SR_RB
> select CPU_HAS_PTEA if !CPU_SH4A || CPU_SHX2
> @@ -130,6 +131,7 @@ config CPU_SH4AL_DSP
>
> config CPU_SH5
> bool
> + select HAVE_HUGETLB_PAGE
> select CPU_HAS_FPU
>
> config CPU_SHX2
> diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
> index 463d1be..3045673 100644
> --- a/arch/sparc64/Kconfig
> +++ b/arch/sparc64/Kconfig
> @@ -16,6 +16,7 @@ config SPARC64
> bool
> default y
> select HAVE_IDE
> + select HAVE_HUGETLB_PAGE
> help
> SPARC is a family of RISC microprocessors designed and marketed by
> Sun Microsystems, incorporated. This port covers the newer 64-bit
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6c70fed..d91e7b7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -22,6 +22,7 @@ config X86
> select HAVE_OPROFILE
> select HAVE_KPROBES
> select HAVE_KRETPROBES
> + select HAVE_HUGETLB_PAGE
> select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
>
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index d731282..f886ae2 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 HAVE_HUGETLB_PAGE || BROKEN
> help
> hugetlbfs is a filesystem backing for HugeTLB pages, based on
> ramfs. For architectures that support it, say Y here and read
> @@ -987,6 +987,7 @@ config HUGETLBFS
> If unsure, say N.
>
> config HUGETLB_PAGE
> + depends on MMU
> def_bool HUGETLBFS
>
> config CONFIGFS_FS
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 0016ebd..3113374 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -90,6 +90,9 @@ config HAVE_MEMORY_PRESENT
> def_bool y
> depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
>
> +config HAVE_HUGETLB_PAGE
> + def_bool n
> +
> #
> # SPARSEMEM_EXTREME (which is the default) does some bootmem
> # allocations when memory_present() is called. If this cannot
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
unsubscribe notice To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/ Messages in current thread:
Re: HugeTLB vs. SH3 cpu , Mel Gorman , (Wed Apr 2, 3:15 am)
