Thread (50 messages) 50 messages, 4 authors, 2016-02-23

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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help