All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Daney <ddaney.cavm@gmail.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"ralf@linux-mips.org" <ralf@linux-mips.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Daney <david.daney@cavium.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Robin Holt <holt@sgi.com>
Subject: Re: [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE
Date: Thu, 17 Nov 2011 15:52:28 -0800	[thread overview]
Message-ID: <4EC59E3C.5070204@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1111171538540.13555@chino.kir.corp.google.com>

On 11/17/2011 03:44 PM, David Rientjes wrote:
> On Thu, 17 Nov 2011, Andrew Morton wrote:
>
>>> So, just remove the dummy and dangerous definitions since they are no
>>> longer needed and reveals the correct dependencies.  Tested on
>>> architectures using the definitions with allyesconfig: x86 (even with
>>> thp), hppa, mips, powerpc, s390, sh3, sh4, sparc, and sparc64, and
>>> with defconfig on ia64.
>>
>> How could arch/mips/mm/tlb-r4k.c:local_flush_tlb_range() compile OK
>> with this change?
>>
>
> This was tested on Linus' tree, not on Ralf's linux-next tree.  All uses
> of HPAGE_* are protected by CONFIG_HUGETLB_PAGE as it appropriately should
> be in Linus' tree in that file.
>
>> What that function is doing looks reasonable to me.  Why fill the poor
>> thing with an ifdef mess?
>>
>> otoh, catching mistakes is good too.  Doing it at runtime as David
>> proposes is OK.
>>
>
> Nobody else needs it other than Ralf's pending change, and you're
> suggesting we need them in a generic header file when any sane arch that
> uses hugepages (all of them, in the current tree) declares these
> themselves in arch/*/include/asm/page.h where it's supposed to be done?
>
> Why on earth do we have CONFIG_HUGETLB_PAGE for at all, then?  To catch
> code that's operating on hugepages when our kernel doesn't support it.
> I'd much rather break the build than get a runtime BUG() because we want
> to avoid an #ifdef or actually write well-written code like every other
> arch has!  Panicking the code to find errors like this is just insanity.
>

A counter argument would be:

There are hundreds of places in the kernel where dummy definitions are 
selected by !CONFIG_* so that we can do:

    if (test_something()) {
       do_one_thing();
    } else {
       do_the_other_thing();
    }


Rather than:

#ifdef CONFIG_SOMETHING
    if (test_something()) {
       do_one_thing();
    } else
#else
    {
       do_the_other_thing();
    }



We even do this all over the place with dummy definitions selected by 
CONFIG_HUGETLB_PAGE, What exactly makes HPAGE_MASK special and not the 
hundreds of other similar situations?

David Daney

  reply	other threads:[~2011-11-17 23:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 21:57 [PATCH v2 0/2] Dummy HPAGE_* constants for !CONFIG_HUGETLB_PAGE David Daney
2011-11-17 21:57 ` [PATCH v2 1/2] hugetlb: Provide a default HPAGE_SHIFT if !CONFIG_HUGETLB_PAGE David Daney
2011-11-17 21:57 ` [PATCH v2 2/2] hugetlb: Provide safer dummy values for HPAGE_MASK and HPAGE_SIZE David Daney
2011-11-17 23:28   ` Andrew Morton
2011-11-17 23:38     ` David Daney
2011-11-18  8:56   ` Sergei Shtylyov
2011-11-18 17:14     ` David Daney
2011-11-17 23:22 ` [PATCH v2 0/2] Dummy HPAGE_* constants for !CONFIG_HUGETLB_PAGE David Rientjes
2011-11-17 23:22   ` [patch] hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE David Rientjes
2011-11-17 23:35     ` Andrew Morton
2011-11-17 23:44       ` David Rientjes
2011-11-17 23:52         ` David Daney [this message]
2011-11-17 23:57           ` Andrew Morton
2011-11-17 23:57           ` David Rientjes
2011-11-21 22:23     ` David Daney
2011-11-21 22:43       ` Linus Torvalds
2011-11-21 23:23         ` David Daney
2011-11-21 23:43           ` Linus Torvalds
2011-11-21 23:50             ` Andrew Morton
2011-11-22 20:41               ` Andi Kleen
2011-11-22 20:41                 ` Andi Kleen
2011-11-21 23:47         ` David Daney
2011-11-21 23:53           ` Andrew Morton
2011-11-22  0:37           ` Linus Torvalds
2011-11-22  0:48             ` David Daney
2011-11-22  0:55               ` Linus Torvalds
2011-11-21 22:48       ` David Rientjes

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=4EC59E3C.5070204@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david.daney@cavium.com \
    --cc=holt@sgi.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rientjes@google.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.