Re: [PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables
From: Paul Mackerras <hidden>
Date: 2016-02-15 05:02:27
Also in:
linuxppc-dev
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... 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? Paul. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>