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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).