All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	Scott Wood <scottwood@freescale.com>,
	Denis Kirjanov <kda@linux-powerpc.org>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2 07/10] powerpc/mm: update PTE frag size
Date: Fri, 27 Nov 2015 17:26:59 +0530	[thread overview]
Message-ID: <87a8pzfyes.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87egfbgav7.fsf@linux.vnet.ibm.com>

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

> "Aneesh Kumar K.V" <aneesh.kumar@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@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

  reply	other threads:[~2015-11-27 11:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 10:33 [PATCH V2 00/10] Reduce the pte framgment size Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 01/10] powerpc/mm: Don't hardcode page table size Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 02/10] powerpc/mm: Don't hardcode the hash pte slot shift Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 03/10] powerpc/nohash: Update 64K nohash config to have 32 pte fragement Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 04/10] powerpc/nohash: we don't use real_pte_t for nohash Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 05/10] powerpc/mm: Use H_READ with H_READ_4 Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 06/10] powerpc/mm: Don't track 4k subpage information with 64k linux page size Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 07/10] powerpc/mm: update PTE frag size Aneesh Kumar K.V
2015-11-27  7:27   ` Aneesh Kumar K.V
2015-11-27 11:56     ` Aneesh Kumar K.V [this message]
2015-11-23 10:33 ` [PATCH V2 08/10] powerpc/mm: Update pte_iterate_hashed_subpages args Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 09/10] powerpc/mm: Drop real_pte_t usage Aneesh Kumar K.V
2015-11-23 10:33 ` [PATCH V2 10/10] powerpc/mm: Optmize the hashed subpage iteration Aneesh Kumar K.V

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=87a8pzfyes.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=kda@linux-powerpc.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.com \
    /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.