All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org,
	paulus@samba.org, mpe@ellerman.id.au,
	khandual@linux.vnet.ibm.com, bsingharora@gmail.com,
	hbabu@us.ibm.com, mhocko@kernel.org
Subject: Re: [PATCH 1/6] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
Date: Thu, 27 Jul 2017 01:00:36 -0700	[thread overview]
Message-ID: <20170727080035.GC5664@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <0aef1bef-c4ad-f745-5efa-07c4c9ae11d5@linux.vnet.ibm.com>

On Thu, Jul 27, 2017 at 07:29:32AM +0530, Aneesh Kumar K.V wrote:
> 
> 
> On 07/26/2017 09:36 PM, Ram Pai wrote:
> >On Wed, Jul 26, 2017 at 04:05:48PM +0530, Aneesh Kumar K.V wrote:
> >>Ram Pai <linuxram@us.ibm.com> writes:
> >>
> 
> >>>diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> >>>index 9732837..62e580c 100644
> >>>--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> >>>+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> >>>@@ -12,18 +12,14 @@
> >>>   */
> >>>  #define H_PAGE_COMBO	_RPAGE_RPN0 /* this is a combo 4k page */
> >>>  #define H_PAGE_4K_PFN	_RPAGE_RPN1 /* PFN is for a single 4k page */
> >>>+#define H_PAGE_BUSY	_RPAGE_RPN42     /* software: PTE & hash are busy */
> >>
> >>
> >>Why are we moving H_PAGE_BUSY. Right now 4k and 64k linux page table
> >>format looks similar.
> >
> >The goal is to clear off all the _RPAGE_RSV* bits so that they can be
> >used for protection keys.  the aim is to keep the protection-bits in the
> >_RPAGE_RSV* bits, so that they will work as-is whenever radix MMU enables
> >protection keys.
> >
> >Yes this makes the PTE format differ from 4k PTE. Hopefully it is a
> >small inconvenience. The PTE format for 4K is anyway not exactly the
> >same compared to 64K PTE format. For example, higher RPN bits are
> >used on 4K but not on 64k. lower RPN bits are used on 64k but not
> >on 4k.
> I was wondering why in this patch ? You do in the next patch

True. because in this patch, we have not yet freed up bit
_RPAGE_RPN44. _RPAGE_RPN44 bit is still used by H_PAGE_F_GIX for 64K
backed HPTEs.  Hence I have temporarily parked H_PAGE_BUSY at
_RPAGE_RPN42.

I could leave H_PAGE_BUSY at bit _RPAGE_RSV1  and move it to 
_RPAGE_RPN44 in the next patch. But by doing so, i would have not
truely released bit _RPAGE_RSV1 for 4K backed hptes; as claimed in the title
of this patch....  

> 
> --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> @@ -12,7 +12,7 @@
>   */
>  #define H_PAGE_COMBO	_RPAGE_RPN0 /* this is a combo 4k page */
>  #define H_PAGE_4K_PFN	_RPAGE_RPN1 /* PFN is for a single 4k page */
> -#define H_PAGE_BUSY	_RPAGE_RPN42     /* software: PTE & hash are busy */
> +#define H_PAGE_BUSY	_RPAGE_RPN44     /* software: PTE & hash are busy */
> 
...
-- 
Ram Pai

  reply	other threads:[~2017-07-27  8:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 18:52 [PATCH 0/6] powerpc: Free up RPAGE_RSV bits in 64K PTE Ram Pai
2017-07-21 18:52 ` [PATCH 1/6] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages Ram Pai
2017-07-26 10:35   ` Aneesh Kumar K.V
2017-07-26 16:06     ` Ram Pai
2017-07-27  1:59       ` Aneesh Kumar K.V
2017-07-27  8:00         ` Ram Pai [this message]
2017-07-21 18:52 ` [PATCH 2/6] powerpc: Free up four 64K PTE bits in 64K " Ram Pai
2017-07-21 18:52 ` [PATCH 3/6] powerpc: capture the PTE format changes in the dump pte report Ram Pai
2017-07-21 18:52 ` [PATCH 4/6] powerpc: introduce pte_set_hash_slot() helper Ram Pai
2017-07-21 18:52 ` [PATCH 5/6] powerpc: introduce pte_get_hash_gslot() helper Ram Pai
2017-07-21 18:52 ` [PATCH 6/6] powerpc: use helper functions to get and set hash slots Ram Pai

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=20170727080035.GC5664@ram.oc3035372033.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=hbabu@us.ibm.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@kernel.org \
    --cc=mpe@ellerman.id.au \
    --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.