All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
Date: Fri, 16 Dec 2016 12:35:12 +0000	[thread overview]
Message-ID: <20161216123512.GF13191@arm.com> (raw)
In-Reply-To: <5853AF6D.20305@huawei.com>

On Fri, Dec 16, 2016 at 05:10:05PM +0800, zhong jiang wrote:
> On 2016/12/14 22:19, zhongjiang wrote:
> > From: zhong jiang <zhongjiang@huawei.com>
> >
> > when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
> > fuctions should not be use. therefore, we add the dependency.
> >
> > Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> > ---
> >  arch/arm64/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 969ef88..694ca73 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
> >  
> >  config ARCH_WANT_HUGE_PMD_SHARE
> >  	def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
> > +	depends on HUGETLB_PAGE
> >  
> >  config ARCH_HAS_CACHE_LINE_SIZE
> >  	def_bool y
> Hi,
>       I still think it is a issue. Perhaps above changelog is unclear.  Further explain is as follows.
>  when hugetlb_pages is disable and arch_want_huge_pmd_share is enable,   we maybe call
>  huge_pmd_sahre in hugetlbpage.c, but the function actually is not definition as it is not
>  exported.  is it right ??

The only users of ARCH_WANT_HUGE_PMD_SHARE on arm64 are:

arch/arm64/mm/hugetlbpage.c:            if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
mm/hugetlb.c:#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
mm/hugetlb.c:#else /* !CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
mm/hugetlb.c:#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */

and neither of those files are compiled if !HUGETLB_PAGE.

Are you actually seeing a problem here?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: catalin.marinas@arm.com, rrichter@cavium.com,
	mark.rutland@arm.com, arnd@arndb.de, ard.biesheuvel@linaro.org,
	robh+dt@kernel.org, dwoods@ezchip.com, jeremy.linton@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
Date: Fri, 16 Dec 2016 12:35:12 +0000	[thread overview]
Message-ID: <20161216123512.GF13191@arm.com> (raw)
In-Reply-To: <5853AF6D.20305@huawei.com>

On Fri, Dec 16, 2016 at 05:10:05PM +0800, zhong jiang wrote:
> On 2016/12/14 22:19, zhongjiang wrote:
> > From: zhong jiang <zhongjiang@huawei.com>
> >
> > when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
> > fuctions should not be use. therefore, we add the dependency.
> >
> > Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> > ---
> >  arch/arm64/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 969ef88..694ca73 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
> >  
> >  config ARCH_WANT_HUGE_PMD_SHARE
> >  	def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
> > +	depends on HUGETLB_PAGE
> >  
> >  config ARCH_HAS_CACHE_LINE_SIZE
> >  	def_bool y
> Hi,
>       I still think it is a issue. Perhaps above changelog is unclear.  Further explain is as follows.
>  when hugetlb_pages is disable and arch_want_huge_pmd_share is enable,   we maybe call
>  huge_pmd_sahre in hugetlbpage.c, but the function actually is not definition as it is not
>  exported.  is it right ??

The only users of ARCH_WANT_HUGE_PMD_SHARE on arm64 are:

arch/arm64/mm/hugetlbpage.c:            if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
mm/hugetlb.c:#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
mm/hugetlb.c:#else /* !CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
mm/hugetlb.c:#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */

and neither of those files are compiled if !HUGETLB_PAGE.

Are you actually seeing a problem here?

Will

  reply	other threads:[~2016-12-16 12:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 14:19 [RESEND PATCH 0/2] fix some trivial bug involving the contiguous bit zhongjiang
2016-12-14 14:19 ` zhongjiang
2016-12-14 14:19 ` [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT zhongjiang
2016-12-14 14:19   ` zhongjiang
2016-12-14 14:45   ` Ard Biesheuvel
2016-12-14 14:45     ` Ard Biesheuvel
2016-12-15  2:59     ` zhong jiang
2016-12-15  2:59       ` zhong jiang
2017-01-03 12:31   ` Catalin Marinas
2017-01-03 12:31     ` Catalin Marinas
2016-12-14 14:19 ` [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE zhongjiang
2016-12-14 14:19   ` zhongjiang
2016-12-16  9:10   ` zhong jiang
2016-12-16  9:10     ` zhong jiang
2016-12-16 12:35     ` Will Deacon [this message]
2016-12-16 12:35       ` Will Deacon
2016-12-16 12:56       ` zhong jiang
2016-12-16 12:56         ` zhong jiang
2016-12-16 14:08       ` zhong jiang
2016-12-16 14:08         ` zhong jiang

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=20161216123512.GF13191@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.