All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: christophe leroy <christophe.leroy@c-s.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Scott Wood <oss@buserror.net>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] powerpc/8xx: implementation of huge pages
Date: Mon, 15 Aug 2016 16:01:37 +0530	[thread overview]
Message-ID: <87a8ge492u.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <a86b0ad2-3a9f-c782-735d-da8072d7b0e1@c-s.fr>

christophe leroy <christophe.leroy@c-s.fr> writes:

> Le 14/08/2016 =C3=A0 16:27, Aneesh Kumar K.V a =C3=A9crit :
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>
>>> This set provides implementation of huge pages on the 8xx
>>>
>>> Christophe Leroy (6):
>>>   powerpc: port 64 bits pgtable_cache to 32 bits
>>>   powerpc: fix usage of _PAGE_RO in hugepage
>>>   powerpc/8xx: use r3 to scratch CR in ITLBmiss
>>>   powerpc/8xx: Move additional DTLBMiss handlers out of exception area
>>>   powerpc/8xx: make user addr DTLB miss the short path
>>>   powerpc/8xx: implementation of huge pages
>>
>> Patch 2,3,4,5 are not really related to hugepage implementation right ?
>> May be that can be sent as a separate series ?
>>
>
> Patch 2 is a lack in gup_hugepte: on 8xx, _PAGE_RW (hence _PAGE_WRITE)=20
> is defined as 0 and _PAGE_RO must be set when the page in not writeable.=
=20
> So that's a prerequisite to implementation of huge page
>
> Patch 3, 4, 5 are prerequisits for the implementation of huge page=20
> handling in the TLB miss handlers:
> * 3: for huge pages implementation we need to branch base of value of=20
> bit 28 and 29 of the PGD entry. For this we need to preserve CR.
> * 4: With the instructions related to hugepages, there is not enough=20
> space anymore in the TLB Exception areas, so part of the it has to be=20
> moved away.
> * 5: That one might be seen as not directly related to hugepages, but it=
=20
> requires patch 3.
>
> Maybe I should reorder into 3, 4, 5, 2, 1, 6 ?
>

Can't 3,4,5,2 be merged independent of the series ? Reading then
suggested they are either fixes or performance improvements ?

-aneesh

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: christophe leroy <christophe.leroy@c-s.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Scott Wood <oss@buserror.net>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] powerpc/8xx: implementation of huge pages
Date: Mon, 15 Aug 2016 16:01:37 +0530	[thread overview]
Message-ID: <87a8ge492u.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <a86b0ad2-3a9f-c782-735d-da8072d7b0e1@c-s.fr>

christophe leroy <christophe.leroy@c-s.fr> writes:

> Le 14/08/2016 à 16:27, Aneesh Kumar K.V a écrit :
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>
>>> This set provides implementation of huge pages on the 8xx
>>>
>>> Christophe Leroy (6):
>>>   powerpc: port 64 bits pgtable_cache to 32 bits
>>>   powerpc: fix usage of _PAGE_RO in hugepage
>>>   powerpc/8xx: use r3 to scratch CR in ITLBmiss
>>>   powerpc/8xx: Move additional DTLBMiss handlers out of exception area
>>>   powerpc/8xx: make user addr DTLB miss the short path
>>>   powerpc/8xx: implementation of huge pages
>>
>> Patch 2,3,4,5 are not really related to hugepage implementation right ?
>> May be that can be sent as a separate series ?
>>
>
> Patch 2 is a lack in gup_hugepte: on 8xx, _PAGE_RW (hence _PAGE_WRITE) 
> is defined as 0 and _PAGE_RO must be set when the page in not writeable. 
> So that's a prerequisite to implementation of huge page
>
> Patch 3, 4, 5 are prerequisits for the implementation of huge page 
> handling in the TLB miss handlers:
> * 3: for huge pages implementation we need to branch base of value of 
> bit 28 and 29 of the PGD entry. For this we need to preserve CR.
> * 4: With the instructions related to hugepages, there is not enough 
> space anymore in the TLB Exception areas, so part of the it has to be 
> moved away.
> * 5: That one might be seen as not directly related to hugepages, but it 
> requires patch 3.
>
> Maybe I should reorder into 3, 4, 5, 2, 1, 6 ?
>

Can't 3,4,5,2 be merged independent of the series ? Reading then
suggested they are either fixes or performance improvements ?

-aneesh

  reply	other threads:[~2016-08-15 10:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-12 16:55 [PATCH 0/6] powerpc/8xx: implementation of huge pages Christophe Leroy
2016-08-12 16:55 ` [PATCH 1/6] powerpc: port 64 bits pgtable_cache to 32 bits Christophe Leroy
2016-08-14 14:17   ` Aneesh Kumar K.V
2016-08-14 18:51     ` christophe leroy
2016-08-15 10:23       ` Aneesh Kumar K.V
2016-08-15 10:23         ` Aneesh Kumar K.V
2016-08-12 16:55 ` [PATCH 2/6] powerpc: fix usage of _PAGE_RO in hugepage Christophe Leroy
2016-08-12 16:55 ` [PATCH 3/6] powerpc/8xx: use r3 to scratch CR in ITLBmiss Christophe Leroy
2016-08-12 16:55 ` [PATCH 4/6] powerpc/8xx: Move additional DTLBMiss handlers out of exception area Christophe Leroy
2016-08-12 16:55 ` [PATCH 5/6] powerpc/8xx: make user addr DTLB miss the short path Christophe Leroy
2016-08-12 16:55 ` [PATCH 6/6] powerpc/8xx: implementation of huge pages Christophe Leroy
2016-08-14 14:25   ` Aneesh Kumar K.V
2016-08-14 17:38     ` christophe leroy
2016-08-15 10:30       ` Aneesh Kumar K.V
2016-08-15 10:30         ` Aneesh Kumar K.V
2016-08-14 14:27 ` [PATCH 0/6] " Aneesh Kumar K.V
2016-08-14 17:33   ` christophe leroy
2016-08-15 10:31     ` Aneesh Kumar K.V [this message]
2016-08-15 10:31       ` 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=87a8ge492u.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=oss@buserror.net \
    --cc=paulus@samba.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.