[PATCH -V7 09/18] powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format

Aneesh Kumar K.V aneesh.kumar at linux.vnet.ibm.com
Fri Jun 7 13:55:22 EST 2013


Scott Wood <scottwood at freescale.com> writes:

> On 04/28/2013 02:37:30 PM, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com>
>> 
>> We will be switching PMD_SHIFT to 24 bits to facilitate THP  
>> impmenetation.
>> With PMD_SHIFT set to 24, we now have 16MB huge pages allocated at  
>> PGD level.
>> That means with 32 bit process we cannot allocate normal pages at
>> all, because we cover the entire address space with one pgd entry.  
>> Fix this
>> by switching to a new page table format for hugepages. With the new  
>> page table
>> format for 16GB and 16MB hugepages we won't allocate hugepage  
>> directory. Instead
>> we encode the PTE information directly at the directory level. This  
>> forces 16MB
>> hugepage at PMD level. This will also make the page take walk much  
>> simpler later
>> when we add the THP support.
>> 
>> With the new table format we have 4 cases for pgds and pmds:
>> (1) invalid (all zeroes)
>> (2) pointer to next table, as normal; bottom 6 bits == 0
>> (3) leaf pte for huge page, bottom two bits != 00
>> (4) hugepd pointer, bottom two bits == 00, next 4 bits indicate size  
>> of table
>> 
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>> ---
>>  arch/powerpc/include/asm/page.h    |   2 +
>>  arch/powerpc/include/asm/pgtable.h |   2 +
>>  arch/powerpc/mm/gup.c              |  18 +++-
>>  arch/powerpc/mm/hugetlbpage.c      | 176  
>> +++++++++++++++++++++++++++++++------
>>  4 files changed, 168 insertions(+), 30 deletions(-)
>
> After this patch, on 64-bit book3e (e5500, and thus 4K pages), I see  
> messages like this after exiting a program that uses hugepages  
> (specifically, qemu):
>
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221516.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221516.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc2214d6.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc2214d6.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221916.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221916.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc2218d6.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc2218d6.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221496.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221496.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221856.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221856.
> /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd  
> 40000001fc221816.

hmm that implies some of the code paths are not properly #ifdef.
The goal was to limit the new format CONFIG_PPC_BOOK3S_64 as seen in the
definition of huge_pte_alloc. Can you send me the .config ?

-aneesh



More information about the Linuxppc-dev mailing list