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$(echo .)ibm.com \
--cc=aneesh.kumar@linux$(echo .)vnet.ibm.com \
--cc=bauerman@linux$(echo .)vnet.ibm.com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=bsingharora@gmail$(echo .)com \
--cc=ebiederm@xmission$(echo .)com \
--cc=hbabu@us$(echo .)ibm.com \
--cc=khandual@linux$(echo .)vnet.ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mhocko@kernel$(echo .)org \
--cc=mpe@ellerman$(echo .)id.au \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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