From: Ram Pai <linuxram@us.ibm.com>
To: mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org,
paulus@samba.org, khandual@linux.vnet.ibm.com,
aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com,
hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com,
ebiederm@xmission.com, linuxram@us.ibm.com
Subject: [PATCH v9 5/8] powerpc: shifted-by-one hidx value
Date: Mon, 6 Nov 2017 00:50:49 -0800 [thread overview]
Message-ID: <1509958252-18302-6-git-send-email-linuxram@us.ibm.com> (raw)
In-Reply-To: <1509958252-18302-1-git-send-email-linuxram@us.ibm.com>
0xf is considered invalid hidx value. It indicates absence of a backing
HPTE. A PTE is initialized to 0xf either
a) when it is new it is newly allocated to hold 4k-backing-HPTE
or
b) Any time it gets demoted to a 4k-backing-HPTE
This patch shifts the representation by one-modulo-0xf; i.e hidx 0 is
represented as 1, 1 as 2,... , and 0xf as 0. This convention lets us
initialize the secondary-part of the PTE to all zeroes. PTEs are anyway
zero'd when allocated. We do not have to zero them again; thus saving on
the initialization.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 14 +++++++++++---
1 files changed, 11 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 73ed988..b78d94e 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -63,13 +63,21 @@ static inline real_pte_t __real_pte(pte_t pte, pte_t *ptep)
return rpte;
}
+/*
+ * shift the hidx representation by one-modulo-0xf; i.e hidx 0 is respresented
+ * as 1, 1 as 2,... , and 0xf as 0. This convention lets us represent a
+ * invalid hidx 0xf with a 0x0 bit value. PTEs are anyway zero'd when
+ * allocated. We dont have to zero them gain; thus save on the initialization.
+ */
+#define HIDX_UNSHIFT_BY_ONE(x) ((x + 0xfUL) & 0xfUL) /* shift backward by one */
+#define HIDX_SHIFT_BY_ONE(x) ((x + 0x1UL) & 0xfUL) /* shift forward by one */
#define HIDX_BITS(x, index) (x << (index << 2))
#define BITS_TO_HIDX(x, index) ((x >> (index << 2)) & 0xfUL)
-#define INVALID_RPTE_HIDX ~(0x0UL)
+#define INVALID_RPTE_HIDX 0x0UL
static inline unsigned long __rpte_to_hidx(real_pte_t rpte, unsigned long index)
{
- return BITS_TO_HIDX(rpte.hidx, index);
+ return HIDX_UNSHIFT_BY_ONE(BITS_TO_HIDX(rpte.hidx, index));
}
/*
@@ -82,7 +90,7 @@ static inline unsigned long pte_set_hidx(pte_t *ptep, real_pte_t rpte,
unsigned long *hidxp = (unsigned long *)(ptep + PTRS_PER_PTE);
rpte.hidx &= ~HIDX_BITS(0xfUL, subpg_index);
- *hidxp = rpte.hidx | HIDX_BITS(hidx, subpg_index);
+ *hidxp = rpte.hidx | HIDX_BITS(HIDX_SHIFT_BY_ONE(hidx), subpg_index);
/*
* Anyone reading PTE must ensure hidx bits are read after reading the
--
1.7.1
next prev parent reply other threads:[~2017-11-06 8:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 8:50 [PATCH v9 0/8] powerpc: Free up RPAGE_RSV bits Ram Pai
2017-11-06 8:50 ` [PATCH v9 1/8] powerpc: introduce pte_set_hidx() helper Ram Pai
2018-01-17 13:30 ` [v9,1/8] " Michael Ellerman
2017-11-06 8:50 ` [PATCH v9 2/8] powerpc: introduce pte_get_hash_gslot() helper Ram Pai
2017-11-06 8:50 ` [PATCH v9 3/8] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages Ram Pai
2017-11-06 8:50 ` [PATCH v9 4/8] powerpc: Free up four 64K PTE bits in 64K " Ram Pai
2017-11-06 8:50 ` Ram Pai [this message]
2017-11-06 8:50 ` [PATCH v9 6/8] powerpc: Swizzle around 4K PTE bits to free up bit 5 and bit 6 Ram Pai
2017-11-06 8:50 ` [PATCH v9 7/8] powerpc: use helper functions to get and set hash slots Ram Pai
2017-11-06 8:50 ` [PATCH v9 8/8] powerpc: capture the PTE format changes in the dump pte report 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=1509958252-18302-6-git-send-email-linuxram@us.ibm.com \
--to=linuxram@us.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bauerman@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bsingharora@gmail.com \
--cc=ebiederm@xmission.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.