[PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables

[Aneesh Kumar K.V]

Paul Mackerras <paulus at ozlabs.org> writes:

> On Mon, Feb 08, 2016 at 02:50:20PM +0530, Aneesh Kumar K.V wrote:
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>> 
>> Inorder to support both current and future ppc64 systems with a single
>> kernel we need to make sure kernel can select between different page
>> table format at runtime. With the new MMU (radix MMU) added, we will
>> have two different pmd hugepage size 16MB for hash model and 2MB for
>> Radix model. Hence make HPAGE_PMD related values as a variable.
>
> But this patch doesn't actually turn any constant into a variable, as
> far as I can see...

This get done in a later patch where we rename PMD_SHIFT to H_PMD_SHIFT.
[PATCH V2 15/29] powerpc/mm: Rename hash specific page table bits (_PAGE* -> H_PAGE*)

>
> Most of what this patch does is to move two tests around:
>
> * The #if HPAGE_PMD_ORDER >= MAX_ORDER test get moved from a generic
> header into all archs except powerpc, and for powerpc it gets turned
> into BUILD_BUG_ON.  However, BUILD_BUG_ON only works on things that
> are known at compile time, last time I looked.  Doesn't it need to be
> a BUG_ON to prepare for HPAGE_PMD_ORDER being a variable that isn't
> known at compile time?
>
> * The existing BUILD_BUG_ON(HPAGE_PMD_ORDER < 2) gets turned into #if
> for all archs except powerpc, and for powerpc it stays as a
> BUILD_BUG_ON but gets moved to arch code.  That doesn't really seem to
> accomplish anything.  Once again, doesn't it need to become a BUG_ON?
> If so, could we just make it BUG_ON in the generic code where the
> BUILD_BUG_ON currently is?

The patch actually got updated after feedback from Kirill
Updated patch here. We still want to fail during build for ppc64. So
there is a BUILD_BUG_ON also added

http://article.gmane.org/gmane.linux.kernel/2148538

-aneesh