From: Becky Bruce <hidden> Date: 2011-10-10 20:51:07
This series of patches contains mostly cleanup code that allows
the enablement of hugetlb for 64-bit Freescale BookE processors.
There are also some bits that I dropped from the 32-bit release
that are added back, as they are needed by other implementations.
Otherwise, it's mostly a bunch of code rearrangement, changes
in #include protections, and Kconfig changes.
Cheers,
Becky
arch/powerpc/configs/corenet32_smp_defconfig | 9 +--
arch/powerpc/configs/corenet64_smp_defconfig | 6 +-
arch/powerpc/configs/mpc85xx_defconfig | 6 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 7 +-
arch/powerpc/include/asm/hugetlb.h | 36 ++++++--
arch/powerpc/include/asm/page_64.h | 2 +
arch/powerpc/kernel/setup_64.c | 10 ++
arch/powerpc/mm/hugetlbpage-book3e.c | 15 ++--
arch/powerpc/mm/hugetlbpage.c | 116 ++++++++++++++++----------
arch/powerpc/mm/tlb_low_64e.S | 36 ++++-----
arch/powerpc/mm/tlb_nohash.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 4 +-
12 files changed, 143 insertions(+), 106 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:08
From: Becky Bruce <redacted>
If we don't have slices, we should be able to use the generic
hugetlb_get_unmapped_area() code
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/include/asm/page_64.h | 2 ++
arch/powerpc/mm/hugetlbpage.c | 6 ++----
2 files changed, 4 insertions(+), 4 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:11
From: Becky Bruce <redacted>
There was an unconditional return of "1" in the original code
from David Gibson, and I dropped it because it wasn't needed
for FSL BOOKE 32-bit. However, not all systems (including 64-bit
FSL BOOKE) do loading of the hpte from the fault handler asm
and depend on this function returning 1, which causes a call
to update_mmu_cache() that writes an entry into the tlb.
Signed-off-by: Becky Bruce <redacted>
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/include/asm/hugetlb.h | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:14
From: Becky Bruce <redacted>
This patch does 2 things: It corrects the code that determines the
size to write into MAS1 for the PPC_MM_SLICES case (this originally
came from David Gibson and I had incorrectly altered it), and it
changes the methodolody used to calculate the size for !PPC_MM_SLICES
to work for 64-bit as well as 32-bit.
Signed-off-by: Becky Bruce <redacted>
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/mm/hugetlbpage-book3e.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:17
From: Becky Bruce <redacted>
This updates the hugetlb page table code to handle 64-bit FSL_BOOKE.
The previous 32-bit work counted on the inner levels of the page table
collapsing.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/mm/hugetlbpage.c | 48 +++++++++++++++++++++++++++++++++++-----
1 files changed, 42 insertions(+), 6 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:20
From: Becky Bruce <redacted>
The original 32-bit hugetlb implementation used PPC64 vs PPC32 to
determine which code path to take. However, the final hugetlb
implementation for 64-bit FSL ended up shared with the FSL
32-bit code so the actual check needs to be FSL_BOOK3E vs
everything else. This patch changes the include protections to
reflect this.
There are also a couple of related comment fixes.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/include/asm/hugetlb.h | 6 ++--
arch/powerpc/mm/hugetlbpage.c | 54 ++++++++++++++++-------------------
arch/powerpc/mm/tlb_nohash.c | 2 +-
3 files changed, 29 insertions(+), 33 deletions(-)
@@ -215,7 +210,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long szreturnhugepte_offset(hpdp,addr,pdshift);}-#ifdef CONFIG_PPC32+#ifdef CONFIG_PPC_FSL_BOOK3E/* Build list of addresses of gigantic pages. This function is used in early*bootbeforethebuddyorbootmemallocatorissetup.*/
@@ -335,7 +330,7 @@ void __init reserve_hugetlb_gpages(void)}}-#else /* PPC64 */+#else /* !PPC_FSL_BOOK3E *//* Build list of addresses of gigantic pages. This function is used in early*bootbeforethebuddyorbootmemallocatorissetup.
@@ -373,7 +368,7 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)return0;}-#ifdef CONFIG_PPC32+#ifdef CONFIG_PPC_FSL_BOOK3E#define HUGEPD_FREELIST_SIZE \((PAGE_SIZE-sizeof(structhugepd_freelist))/sizeof(pte_t))
@@ -433,11 +428,11 @@ static void free_hugepd_range(struct mmu_gather *tlb, hugepd_t *hpdp, int pdshifunsignedlongpdmask=~((1UL<<pdshift)-1);unsignedintnum_hugepd=1;-#ifdef CONFIG_PPC64-unsignedintshift=hugepd_shift(*hpdp);-#else-/* Note: On 32-bit the hpdp may be the first of several */+#ifdef CONFIG_PPC_FSL_BOOK3E+/* Note: On fsl the hpdp may be the first of several */num_hugepd=(1<<(hugepd_shift(*hpdp)-pdshift));+#else+unsignedintshift=hugepd_shift(*hpdp);#endifstart&=pdmask;
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:23
From: Becky Bruce <redacted>
I happened to comment this code while I was digging through it;
we might as well commit that. I also made some whitespace
changes - the existing code had a lot of unnecessary newlines
that I found annoying when I was working on my tiny laptop.
No functional changes.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/mm/tlb_low_64e.S | 28 +++++++++++-----------------
1 files changed, 11 insertions(+), 17 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:27
From: Becky Bruce <redacted>
Before hugetlb, at each level of the table, we test for
!0 to determine if we have a valid table entry. With hugetlb, this
compare becomes:
< 0 is a normal entry
0 is an invalid entry
> 0 is huge
This works because the hugepage code pulls the top bit off the entry
(which for non-huge entries always has the top bit set) as an
indicator that we have a hugepage.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/mm/tlb_low_64e.S | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:29
From: Becky Bruce <redacted>
For 64-bit FSL_BOOKE implementations, gigantic pages need to be
reserved at boot time by the memblock code based on the command line.
This adds the call that handles the reservation, and fixes some code
comments.
It also removes the previous pr_err when reserve_hugetlb_gpages
is called on a system without hugetlb enabled - the way the code is
structured, the call is unconditional and the resulting error message
spurious and confusing.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/include/asm/hugetlb.h | 19 ++++++++++++++-----
arch/powerpc/kernel/setup_64.c | 10 ++++++++++
arch/powerpc/mm/hugetlbpage.c | 8 ++++----
3 files changed, 28 insertions(+), 9 deletions(-)
From: Becky Bruce <hidden> Date: 2011-10-10 20:51:33
From: Becky Bruce <redacted>
Allow hugetlb to be enabled on 64b FSL_BOOK3E. No platforms enable
it by default yet.
Signed-off-by: Becky Bruce <redacted>
---
arch/powerpc/platforms/Kconfig.cputype | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
@@ -174,7 +174,6 @@ config BOOKEconfigFSL_BOOKEbooldepends on(E200||E500)&&PPC32-selectSYS_SUPPORTS_HUGETLBFSifPHYS_64BITdefaulty# this is for common code between PPC32 & PPC64 FSL BOOKE
@@ -107,7 +104,6 @@ CONFIG_FSL_PQ_MDIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_SERIO_LIBPS2=y # CONFIG_LEGACY_PTYS is not set-CONFIG_PPC_EPAPR_HV_BYTECHAN=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y
@@ -146,7 +140,6 @@ CONFIG_RTC_DRV_DS3232=y CONFIG_RTC_DRV_CMOS=y CONFIG_UIO=y CONFIG_STAGING=y-# CONFIG_STAGING_EXCLUDE_BUILD is not set CONFIG_VIRT_DRIVERS=y CONFIG_FSL_HV_MANAGER=y CONFIG_EXT2_FS=y
@@ -123,6 +120,7 @@ CONFIG_NVRAM=y CONFIG_I2C=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y+CONFIG_GPIO_MPC8XXX=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y
@@ -124,6 +121,7 @@ CONFIG_NVRAM=y CONFIG_I2C=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y+CONFIG_GPIO_MPC8XXX=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y
@@ -207,10 +205,8 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y CONFIG_CRC_T10DIF=y CONFIG_DEBUG_FS=y-CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y-# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_VIRQ_DEBUG=y CONFIG_CRYPTO_PCBC=m
@@ -11,10 +11,8 @@ CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_BLK_DEV_INITRD=y-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y-CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y
@@ -25,7 +23,6 @@ CONFIG_P5020_DS=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BINFMT_MISC=m-# CONFIG_PCI is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y
@@ -93,10 +90,8 @@ CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=m CONFIG_FRAME_WARN=1024 CONFIG_DEBUG_FS=y-CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y-# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_VIRQ_DEBUG=y CONFIG_CRYPTO_PCBC=m
@@ -81,6 +81,7 @@ CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_PROC_KCORE=y CONFIG_TMPFS=y+CONFIG_HUGETLBFS=y # CONFIG_MISC_FILESYSTEMS is not set CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y
Now, I know it was already there and you are just moving it around in
this patch but come on ... find_vma() here ? Really ? And with no result
checking nor boundary checking (remember it can return a vma that
doesn't enclose the address etc....). Now I know in this specific case
it -should- be safe but still...
Now, the caller is just doing:
book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
So why not just change the prototype and pass the vma down instead ?
Cheers,
Ben.
=20
Now, I know it was already there and you are just moving it around in
this patch but come on ... find_vma() here ? Really ? And with no =
result
checking nor boundary checking (remember it can return a vma that
doesn't enclose the address etc....). Now I know in this specific case
it -should- be safe but still...
=20
Now, the caller is just doing:
=20
book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
=20
So why not just change the prototype and pass the vma down instead ?
Can we do this on top of the patchset instead of changing the existing =
patchset?
- k=
=20
Now, I know it was already there and you are just moving it around in
this patch but come on ... find_vma() here ? Really ? And with no =
result
checking nor boundary checking (remember it can return a vma that
doesn't enclose the address etc....). Now I know in this specific case
it -should- be safe but still...
=20
Now, the caller is just doing:
=20
book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
=20
So why not just change the prototype and pass the vma down instead ?
There's no reason - I just left the prototype the way it was in the =
original code, but it makes sense to change it given the changes to the =
function. Respin coming.....
-B
BTW. Can you remind me what is the business with slices vs. no slices on
Book3E ?
I'd like to avoid having to build separate kernels for A2 vs. FSL ...
Cheers,
Ben.
The above conditional makes my brain hurt. Can you change that to
instead
#ifdef HUGETLB_NEED_PRELOAD
... or something like that, which you then #define in the right
mmu-xxxx.h header ?
Cheers,
Ben.
+ /*
+ * The "return 1" forces a call of update_mmu_cache, which will write a
+ * TLB entry. Without this, platforms that don't do a write of the TLB
+ * entry in the TLB miss handler asm will fault ad infinitum.
+ */
+ ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+ return 1;
+#else
return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+#endif
}
static inline pte_t huge_ptep_get(pte_t *ptep)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-11-29 05:25:44
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
From: Becky Bruce <redacted>
This updates the hugetlb page table code to handle 64-bit FSL_BOOKE.
The previous 32-bit work counted on the inner levels of the page table
collapsing.
Seriously, my brain hurts !!!
So I've tried to understand that code and so far, what I came up with is
this, please reply and let me know if I'm full of crack or what ...
- David's code has entire levels "branching off" into hugepd's which
are hugetlb specific page dirs. That requires address space constrainst.
- The hack you do with HUGEPD_PGD_SHIFT defined to PGDIR_SHIFT and
HUGEPD_PUD_SHIFT to PUD_SHIFT consists of collasping that back into the
normal levels.
- I really don't understand what you are doing in __hugepte_alloc(). It
seems to me that you are trying to make things still point to some kind
of separate hugepd dir with the hugeptes in it and have the page tables
point to that but I don't quite get it.
- Couldn't we just instead ditch the whole hugepd concept alltogether
and simply have the huge ptes in the page table at the right level,
using possibly multiple consecutive of them for a single page when
needed ?
Example: 4K base page size. PMD maps 2M. a 16M page could be
representing by having 8 consecutive hugeptes pointing to the same huge
page in the PMD directory.
I believe we always "know" when accessing a PTE whether it's going to be
huge or not and if it's huge, the page size. IE. All the functions we
care about either get the vma (which gets you everything you need) or
the size (huge_pte_alloc).
This should be much simpler than what we have today.
That way, we have a completely generic accross-the-board way to store
huge pte's in our page tables, which is totally disconnected from the
slices. The later remains a purely server-only thing which only affects
the SLB code and get_unmapped_area().
That means that we'll have to find another option for PowerEN giant
indirects but that's a non issue at the moment. I think we can keep the
complexity local to the PowerEN code by doing shadows there if we need
to.
What do you think ?
Ben.
From: Becky Bruce <hidden> Date: 2011-11-29 16:36:55
On Nov 28, 2011, at 11:25 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
quoted
From: Becky Bruce <redacted>
=20
This updates the hugetlb page table code to handle 64-bit FSL_BOOKE.
The previous 32-bit work counted on the inner levels of the page =
table
quoted
collapsing.
=20
Seriously, my brain hurts !!!
Now you know how I felt when I got the original code from David :)
=20
So I've tried to understand that code and so far, what I came up with =
is
this, please reply and let me know if I'm full of crack or what ...
=20
- David's code has entire levels "branching off" into hugepd's which
are hugetlb specific page dirs. That requires address space =
constrainst.
Yes.
=20
- The hack you do with HUGEPD_PGD_SHIFT defined to PGDIR_SHIFT and
HUGEPD_PUD_SHIFT to PUD_SHIFT consists of collasping that back into =
the
normal levels.
That exists so Jimi's code for A2 and mine can coexist peacefully =
without ifdeffing huge blocks because we peel off the page table at =
different points for a hugepd. In my case, if I have a 4M page, that is =
handled by having 2 entries at the 2M layer, each of which is a pointer =
to the same pte stored in a kmem_cache created for that purpose. In the =
server/A2 case, they peel off at the layer above 4M and have a sub-table =
kmem_cache that has a bunch of same-size huge page ptes (this is all =
because of the slice constraint).
=20
- I really don't understand what you are doing in __hugepte_alloc(). =
It
seems to me that you are trying to make things still point to some =
kind
of separate hugepd dir with the hugeptes in it and have the page =
tables
point to that but I don't quite get it.
In your example below, the alloc code is:
1) allocating a small kmem_cache for the pte
2) filling in 8 entries at the 2M level with the pointers to that pte, =
with the upper bit munged to indicate huge and bits in the lower region =
that store the huge page size because it can't be encoded in the book3e =
pte format
=20
- Couldn't we just instead ditch the whole hugepd concept alltogether
and simply have the huge ptes in the page table at the right level,
using possibly multiple consecutive of them for a single page when
needed ?
=20
Example: 4K base page size. PMD maps 2M. a 16M page could be
representing by having 8 consecutive hugeptes pointing to the same =
huge
page in the PMD directory.
We currently have 8 consecutive PMD entries that are pointers to the =
same kmem_cache that holds the actual PTE. I did this for a few =
reasons:
1) I was trying to stay as close to what David had done as possible
2) symmetry - in every other case entries at higher levels of the normal =
page table are pointers to something, and it's easy to identify that =
something is a pointer to hugepte using David's upper-bit-flipping =
trick. If we have an actual entry mixed in with the pointers it might =
be hard to tell that's it's an actual PTE and not a pointer without =
getting information from somewhere else (i.e. the vma)
3) I was trying to avoid having multiple copies of the actual pte - this =
way it's easy to do stuff like change the perms on the PTE, since I only =
have to modify one copy
4) I needed the information laid out for quick TLB miss fault-handling =
of hugepte tlb misses (see below).
=20
I believe we always "know" when accessing a PTE whether it's going to =
be
huge or not and if it's huge, the page size. IE. All the functions we
care about either get the vma (which gets you everything you need) or
the size (huge_pte_alloc).
An exception is the 32-bit fault hander asm code. It does a walk of the =
page table to reload the tlb. We need to be able to easily identify =
that we're walking into a hugepage area so we know to load the tlbcam. =
Having the pointer there with the munged upper bit that David devised is =
very convenient for that. Also, the Book3e page table format does not =
allow us to represent page sizes > 32m. So that's encoded in the hugepd =
instead (and not in the pte).
I'm not sure how to get around this without slowing things down. I =
originally had a slower handler and it turned out to impact performance =
of several important workloads and my perf guys griped at me. I was =
actually eventually planning to rewrite the 64b fsl book3e handler to =
deal with this in asm as well. Large workloads on our systems do a lot =
of tlbcam entry replacement due to 1) the small size of the tlbcam and =
2) the lack of any hardware replacement policy on that array.
There are other places where we'd have to modify the code to have the =
vma available (not that it's hard to do, but it's not floating around =
everywhere). And there may be other places where this is an issue - I'd =
have to go dig around a bit to answer that.
For the record, I hate the idea of not being able to walk the page table =
without going elsewhere for information. IMHO I should be able to tell =
everything I need to load a TLB entry from there without digging up a =
vma.
=20
This should be much simpler than what we have today.
=20
That way, we have a completely generic accross-the-board way to store
huge pte's in our page tables, which is totally disconnected from the
slices. The later remains a purely server-only thing which only =
affects
the SLB code and get_unmapped_area().
David and Jimi will have to comment about whether they can flatten out =
their stuff to just store PTEs. A lot of my code exists because I was =
attempting to be as close to the IBM implementation as possible.
=20
That means that we'll have to find another option for PowerEN giant
indirects but that's a non issue at the moment. I think we can keep =
the
complexity local to the PowerEN code by doing shadows there if we need
to.
=20
What do you think ?
I'm happy if we can come up with another solution that still allows me =
to do my miss fault handling efficiently in asm.... What we do on FSL =
Booke with storing multiple pointers to a single pte is actually a =
fairly clean solution given the constraints. It's only in the context =
of having a different implementation coexisting with it that makes =
things start getting complicated. If you have some suggestions on =
another way to deal with this, I'm all ears.
Cheers,
B
=20
The above conditional makes my brain hurt. Can you change that to
instead
=20
#ifdef HUGETLB_NEED_PRELOAD
=20
... or something like that, which you then #define in the right
mmu-xxxx.h header ?
Sure.
Can I publish this as a followup instead of rebasing? We're trying to =
stay sync'ed with what's in our BSP and it would be easier for me/Kumar =
to deal with.
Cheers,
B
=20
Cheers,
Ben.
=20
=20
quoted
+ /*
+ * The "return 1" forces a call of update_mmu_cache, which will =
write a
quoted
+ * TLB entry. Without this, platforms that don't do a write of =
the TLB
quoted
+ * entry in the TLB miss handler asm will fault ad infinitum.
+ */
+ ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+ return 1;
+#else
return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+#endif
}
=20
static inline pte_t huge_ptep_get(pte_t *ptep)
From: David Gibson <hidden> Date: 2011-11-30 01:10:18
On Tue, Nov 29, 2011 at 10:36:42AM -0600, Becky Bruce wrote:
On Nov 28, 2011, at 11:25 PM, Benjamin Herrenschmidt wrote:
quoted
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
quoted
From: Becky Bruce <redacted>
This updates the hugetlb page table code to handle 64-bit FSL_BOOKE.
The previous 32-bit work counted on the inner levels of the page table
collapsing.
Seriously, my brain hurts !!!
Now you know how I felt when I got the original code from David :)
Heh, I can't blame you. Between the constraints of the hardware and
fitting in with x86, that thing's accreted into a horrible pile.
quoted
So I've tried to understand that code and so far, what I came up with is
this, please reply and let me know if I'm full of crack or what ...
- David's code has entire levels "branching off" into hugepd's which
are hugetlb specific page dirs. That requires address space constrainst.
Yes.
quoted
- The hack you do with HUGEPD_PGD_SHIFT defined to PGDIR_SHIFT and
HUGEPD_PUD_SHIFT to PUD_SHIFT consists of collasping that back into the
normal levels.
That exists so Jimi's code for A2 and mine can coexist peacefully
without ifdeffing huge blocks because we peel off the page table at
different points for a hugepd. In my case, if I have a 4M page,
that is handled by having 2 entries at the 2M layer, each of which
is a pointer to the same pte stored in a kmem_cache created for that
purpose. In the server/A2 case, they peel off at the layer above 4M
and have a sub-table kmem_cache that has a bunch of same-size huge
page ptes (this is all because of the slice constraint).
quoted
- I really don't understand what you are doing in __hugepte_alloc(). It
seems to me that you are trying to make things still point to some kind
of separate hugepd dir with the hugeptes in it and have the page tables
point to that but I don't quite get it.
In your example below, the alloc code is:
1) allocating a small kmem_cache for the pte
2) filling in 8 entries at the 2M level with the pointers to that pte, with the upper bit munged to indicate huge and bits in the lower region that store the huge page size because it can't be encoded in the book3e pte format
quoted
- Couldn't we just instead ditch the whole hugepd concept alltogether
and simply have the huge ptes in the page table at the right level,
using possibly multiple consecutive of them for a single page when
needed ?
Example: 4K base page size. PMD maps 2M. a 16M page could be
representing by having 8 consecutive hugeptes pointing to the same huge
page in the PMD directory.
We currently have 8 consecutive PMD entries that are pointers to the
same kmem_cache that holds the actual PTE. I did this for a few
reasons:
1) I was trying to stay as close to what David had done as possible
2) symmetry - in every other case entries at higher levels of the
normal page table are pointers to something, and it's easy to
identify that something is a pointer to hugepte using David's
upper-bit-flipping trick. If we have an actual entry mixed in with
the pointers it might be hard to tell that's it's an actual PTE and
not a pointer without getting information from somewhere else
(i.e. the vma)
3) I was trying to avoid having multiple copies of the actual pte -
this way it's easy to do stuff like change the perms on the PTE,
since I only have to modify one copy
4) I needed the information laid out for quick TLB miss
fault-handling of hugepte tlb misses (see below).
quoted
I believe we always "know" when accessing a PTE whether it's going to be
huge or not and if it's huge, the page size. IE. All the functions we
care about either get the vma (which gets you everything you need) or
the size (huge_pte_alloc).
An exception is the 32-bit fault hander asm code. It does a walk of
the page table to reload the tlb. We need to be able to easily
identify that we're walking into a hugepage area so we know to load
the tlbcam. Having the pointer there with the munged upper bit that
David devised is very convenient for that. Also, the Book3e page
table format does not allow us to represent page sizes > 32m. So
that's encoded in the hugepd instead (and not in the pte).
I'm not sure how to get around this without slowing things down. I
originally had a slower handler and it turned out to impact
performance of several important workloads and my perf guys griped
at me. I was actually eventually planning to rewrite the 64b fsl
book3e handler to deal with this in asm as well. Large workloads on
our systems do a lot of tlbcam entry replacement due to 1) the small
size of the tlbcam and 2) the lack of any hardware replacement
policy on that array.
There are other places where we'd have to modify the code to have
the vma available (not that it's hard to do, but it's not floating
around everywhere). And there may be other places where this is an
issue - I'd have to go dig around a bit to answer that.
For the record, I hate the idea of not being able to walk the page
table without going elsewhere for information. IMHO I should be
able to tell everything I need to load a TLB entry from there
without digging up a vma.
I agree, all things being equal, but there might be tradeoffs that
make it the least bad option.
quoted
This should be much simpler than what we have today.
That way, we have a completely generic accross-the-board way to store
huge pte's in our page tables, which is totally disconnected from the
slices. The later remains a purely server-only thing which only affects
the SLB code and get_unmapped_area().
David and Jimi will have to comment about whether they can flatten
out their stuff to just store PTEs. A lot of my code exists because
I was attempting to be as close to the IBM implementation as
possible.
I was talking with Ben about this yesterday, and I think it can
probably be done.
quoted
That means that we'll have to find another option for PowerEN giant
indirects but that's a non issue at the moment. I think we can keep the
complexity local to the PowerEN code by doing shadows there if we need
to.
What do you think ?
I'm happy if we can come up with another solution that still allows
me to do my miss fault handling efficiently in asm.... What we do on
FSL Booke with storing multiple pointers to a single pte is actually
a fairly clean solution given the constraints. It's only in the
context of having a different implementation coexisting with it that
makes things start getting complicated. If you have some
suggestions on another way to deal with this, I'm all ears.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Tabi Timur-B04825 <hidden> Date: 2011-12-09 22:05:25
On Mon, Oct 10, 2011 at 3:50 PM, Becky Bruce [off-list ref] w=
rote:
From: Becky Bruce <redacted>
Results from updates via make savedefconfig.
Signed-off-by: Becky Bruce <redacted>
---
...
-CONFIG_PPC_EPAPR_HV_BYTECHAN=3Dy
I guess no one noticed that this patch removes byte channel support,
thereby preventing this kernel from booting under the hypervisor?
--=20
Timur Tabi
Linux kernel developer at Freescale=