From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: benh@kernel.crashing.org, mpe@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables
Date: Tue, 16 Feb 2016 13:42:42 +0530 [thread overview]
Message-ID: <874md9f4zp.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160215041153.GC3797@oak.ozlabs.ibm.com>
Paul Mackerras <paulus@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
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: benh@kernel.crashing.org, mpe@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: [PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables
Date: Tue, 16 Feb 2016 13:42:42 +0530 [thread overview]
Message-ID: <874md9f4zp.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160215041153.GC3797@oak.ozlabs.ibm.com>
Paul Mackerras <paulus@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
--
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>
next prev parent reply other threads:[~2016-02-16 8:12 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 9:20 [PATCH V2 00/29] Book3s abstraction in preparation for new MMU model Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 01/29] powerpc/mm: add _PAGE_HASHPTE similar to 4K hash Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-12 2:49 ` Paul Mackerras
2016-02-12 2:49 ` Paul Mackerras
2016-02-13 5:08 ` Aneesh Kumar K.V
2016-02-13 5:08 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 02/29] powerpc/mm: Split pgtable types to separate header Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-12 2:52 ` Paul Mackerras
2016-02-12 2:52 ` Paul Mackerras
2016-02-13 5:12 ` Aneesh Kumar K.V
2016-02-13 5:12 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 03/29] powerpc/mm: Switch book3s 64 with 64K page size to 4 level page table Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 04/29] powerpc/mm: Copy pgalloc (part 1) Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 05/29] powerpc/mm: Copy pgalloc (part 2) Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-12 3:53 ` Paul Mackerras
2016-02-12 3:53 ` Paul Mackerras
2016-02-15 5:25 ` Aneesh Kumar K.V
2016-02-15 5:25 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 06/29] powerpc/mm: Copy pgalloc (part 3) Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 07/29] mm: Make vm_get_page_prot arch specific Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-15 3:21 ` Paul Mackerras
2016-02-15 3:21 ` Paul Mackerras
2016-02-15 4:40 ` Aneesh Kumar K.V
2016-02-15 4:40 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-15 4:11 ` Paul Mackerras
2016-02-15 4:11 ` Paul Mackerras
2016-02-16 8:12 ` Aneesh Kumar K.V [this message]
2016-02-16 8:12 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 09/29] powerpc/mm: Hugetlbfs is book3s_64 and fsl_book3e (32 or 64) Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-15 5:01 ` Paul Mackerras
2016-02-15 5:01 ` Paul Mackerras
2016-02-16 8:20 ` Aneesh Kumar K.V
2016-02-16 8:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 10/29] powerpc/mm: free_hugepd_range split to hash and nonhash Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 11/29] powerpc/mm: Use helper instead of opencoding Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 12/29] powerpc/mm: Move hash64 specific defintions to seperate header Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-15 5:24 ` Paul Mackerras
2016-02-15 5:24 ` Paul Mackerras
2016-02-16 8:25 ` Aneesh Kumar K.V
2016-02-16 8:25 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 13/29] powerpc/mm: Move swap related definition ot hash64 header Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 14/29] powerpc/mm: Move hash page table related functions to pgtable-hash64.c Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 15/29] powerpc/mm: Rename hash specific page table bits (_PAGE* -> H_PAGE*) Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 16/29] powerpc/mm: Use flush_tlb_page in ptep_clear_flush_young Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 17/29] powerpc/mm: THP is only available on hash64 as of now Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 18/29] powerpc/mm: Use generic version of pmdp_clear_flush_young Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 19/29] powerpc/mm: Create a new headers for tlbflush for hash64 Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 20/29] powerpc/mm: Hash linux abstraction for page table accessors Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 21/29] powerpc/mm: Hash linux abstraction for functions in pgtable-hash.c Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 22/29] powerpc/mm: Hash linux abstraction for mmu context handling code Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 23/29] powerpc/mm: Move hash related mmu-*.h headers to book3s/ Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 24/29] powerpc/mm: Hash linux abstractions for early init routines Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 25/29] powerpc/mm: Hash linux abstraction for THP Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 26/29] powerpc/mm: Hash linux abstraction for HugeTLB Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 27/29] powerpc/mm: Hash linux abstraction for page table allocator Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 28/29] powerpc/mm: Hash linux abstraction for tlbflush routines Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-08 9:20 ` [PATCH V2 29/29] powerpc/mm: Hash linux abstraction for pte swap encoding Aneesh Kumar K.V
2016-02-08 9:20 ` Aneesh Kumar K.V
2016-02-09 13:22 ` [PATCH V2 00/29] Book3s abstraction in preparation for new MMU model Aneesh Kumar K.V
2016-02-09 13:22 ` Aneesh Kumar K.V
2016-02-23 1:59 ` Scott Wood
2016-02-23 1:59 ` Scott Wood
2016-02-23 2:17 ` Aneesh Kumar K.V
2016-02-23 2:17 ` Aneesh Kumar K.V
2016-02-12 4:14 ` Paul Mackerras
2016-02-12 4:14 ` Paul Mackerras
2016-02-13 5:15 ` Aneesh Kumar K.V
2016-02-13 5:15 ` Aneesh Kumar K.V
2016-02-13 8:39 ` Denis Kirjanov
2016-02-13 8:39 ` Denis Kirjanov
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=874md9f4zp.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@ozlabs.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.