[PATCH V2 07/10] powerpc/mm: update PTE frag size

Aneesh Kumar K.V aneesh.kumar at linux.vnet.ibm.com
Fri Nov 27 22:56:59 AEDT 2015


"Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com> writes:

> "Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com> writes:
>
>> Now that we don't track 4k subpage information we can use 2K PTE
>> fragments.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>> ---
>>  arch/powerpc/include/asm/book3s/64/hash-64k.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> index 5062c6d423fd..a28dbfe2baed 100644
>> --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> @@ -39,14 +39,14 @@
>>   */
>>  #define PTE_RPN_SHIFT	(30)
>>  /*
>> - * we support 8 fragments per PTE page of 64K size.
>> + * we support 32 fragments per PTE page of 64K size.
>>   */
>> -#define PTE_FRAG_NR	8
>> +#define PTE_FRAG_NR	32
>>  /*
>>   * We use a 2K PTE page fragment and another 4K for storing
>>   * real_pte_t hash index. Rounding the entire thing to 8K
>>   */
>> -#define PTE_FRAG_SIZE_SHIFT  13
>> +#define PTE_FRAG_SIZE_SHIFT  11
>>  #define PTE_FRAG_SIZE (1UL << PTE_FRAG_SIZE_SHIFT)
>>
>
>
> This break THP with 4k hpte support because we need to track 4096
> subpage information,  and we have only 2048 bytes after this change.
>
> Another thing I noticed is the impact of not tracking subpage
> information. We do see some significant impact as shown by the mmtest
> results below. The plan now is to go back to 4K pte framgments but
> instead of using 16 bits to track 4k subpage valid bit in pte, we use only 4
> bits as the last patch in this series does ("[PATCH V2 10/10]
> powerpc/mm: Optmize the hashed subpage iteration"). We will track the
> secondary and slot information on the second half. This will result in us using
> hidx value 0x0, wrongly. This actually indicate primary hash with slot
> number zero. But since we are not going to track individual 4k
> subpage information we may using slot 0 wrongly. I checked the existing
> code and we should be able to handle that case gracefuly.

I pushed the changes to 

https://github.com/kvaneesh/linux/commits/book3s-pte-format-v2

This needs full round of testing. I only did a sanity test with
4k hash pte config. Will send an updated series once I finish testing.
Meanwhile if you are interested please take a look

-aneesh



More information about the Linuxppc-dev mailing list