ppc: Add support for bigger page sizes than 4KB on PPC44x
PATCH 1/1 ppc: Add support for bigger page sizes than 4KB on PPC44x
This patch adds support for the PAGE_SIZE set equal to 64 KB on PPC32 platforms. Increasing the PAGE_SIZE may improve the performance of the system in some cases.
The RAID processing with the dedicated hardware that offloads the CPU is one of such cases. Using the bigger PAGE_SIZE we decrease the number of CPU operations required to process the data blocks, decrease the control overheads and so improve the overall performance. For example, changing the PAGE_SIZE from 4KB to 64KB on a Yucca (440SPe) gives ~300% performance benefit of the full-stripe writing in the (7d+1p) RAID-5 setup.
---
commit 1222edca342590c856ca05aa5fed1281ba23c8a3
tree 3bea891dcdee9444b1800a00a1e0f33c157b254d
parent be521466feb3bb1cd89de82a2b1d080e9ebd3cb6
author Yuri Tikhonov <[email protected]> Mon, 12 Mar 2007 22:49:21 +0100 committer Stefan Roese <[email protected]> Mon, 12 Mar 2007 22:49:21 +0100
arch/ppc/Kconfig | 10 ++++++++ arch/ppc/kernel/head_44x.S | 23 ++++++++++--------- arch/ppc/kernel/misc.S | 13 ++++++----- arch/ppc/kernel/vmlinux.lds.S | 15 +++++++----- include/asm-ppc/page.h | 6 ++++- include/asm-ppc/ppc_page_asm.h | 49 ++++++++++++++++++++++++++++++++++++++++ 6 files changed, 91 insertions(+), 25 deletions(-)
arch/ppc/Kconfig +10 -0
@@ -1174,6 +1174,16 @@ config SECCOMP If unsure, say Y. Only embedded should say N here. +config PPC_PAGE_SHIFT + int "Page size (12=>4KB; 16=>64KB)" + default "12" + range 12 16 + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + + If unsure, set it to 12 (4KB). + endmenu config ISA_DMA_API
arch/ppc/kernel/head_44x.S +12 -11
@@ -38,6 +38,7 @@ #include <asm/thread_info.h> #include <asm/ppc_asm.h> #include <asm/asm-offsets.h> +#include <asm/ppc_page_asm.h> #include "head_booke.h"
@@ -183,7 +184,7 @@ skpinv: addi r4,r4,1 /* Increment */ */ /* pageid fields */ lis r3,UART0_IO_BASE@h - ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_4K + ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_SIZE /* xlat fields */ lis r4,UART0_PHYS_IO_BASE@h /* RPN depends on SoC */
@@ -363,12 +364,12 @@ interrupt_base: 4: mtspr SPRN_MMUCR,r12 - rlwinm r12, r10, 13, 19, 29 /* Compute pgdir/pmd offset */ + rlwinm r12, r10, PPC44x_PGD_OFF_SH, PPC44x_PGD_OFF_M1, 29 /* Compute pgdir/pmd offset */ lwzx r11, r12, r11 /* Get pgd/pmd entry */ rlwinm. r12, r11, 0, 0, 20 /* Extract pt base address */ beq 2f /* Bail if no table */ - rlwimi r12, r10, 23, 20, 28 /* Compute pte address */ + rlwimi r12, r10, PPC44x_PTE_ADD_SH, PPC44x_PTE_ADD_M1, 28 /* Compute pte address */ lwz r11, 4(r12) /* Get pte entry */ andi. r13, r11, _PAGE_RW /* Is it writeable? */
@@ -502,12 +503,12 @@ interrupt_base: 4: mtspr SPRN_MMUCR,r12 - rlwinm r12, r10, 13, 19, 29 /* Compute pgdir/pmd offset */ + rlwinm r12, r10, PPC44x_PGD_OFF_SH, PPC44x_PGD_OFF_M1, 29 /* Compute pgdir/pmd offset */ lwzx r11, r12, r11 /* Get pgd/pmd entry */ rlwinm. r12, r11, 0, 0, 20 /* Extract pt base address */ beq 2f /* Bail if no table */ - rlwimi r12, r10, 23, 20, 28 /* Compute pte address */ + rlwimi r12, r10, PPC44x_PTE_ADD_SH, PPC44x_PTE_ADD_M1, 28 /* Compute pte address */ lwz r11, 4(r12) /* Get pte entry */ andi. r13, r11, _PAGE_PRESENT /* Is the page present? */ beq 2f /* Bail if not present */
@@ -572,12 +573,12 @@ interrupt_base: 4: mtspr SPRN_MMUCR,r12 - rlwinm r12, r10, 13, 19, 29 /* Compute pgdir/pmd offset */ + rlwinm r12, r10, PPC44x_PGD_OFF_SH, PPC44x_PGD_OFF_M1, 29 /* Compute pgdir/pmd offset */ lwzx r11, r12, r11 /* Get pgd/pmd entry */ rlwinm. r12, r11, 0, 0, 20 /* Extract pt base address */ beq 2f /* Bail if no table */ - rlwimi r12, r10, 23, 20, 28 /* Compute pte address */ + rlwimi r12, r10, PPC44x_PTE_ADD_SH, PPC44x_PTE_ADD_M1, 28 /* Compute pte address */ lwz r11, 4(r12) /* Get pte entry */ andi. r13, r11, _PAGE_PRESENT /* Is the page present? */ beq 2f /* Bail if not present */
@@ -656,14 +657,14 @@ finish_tlb_load: lwz r11, 0(r12) /* Get MS word of PTE */ lwz r12, 4(r12) /* Get LS word of PTE */ - rlwimi r11, r12, 0, 0 , 19 /* Insert RPN */ + rlwimi r11, r12, 0, 0 , PPC44x_RPN_M2 /* Insert RPN */ tlbwe r11, r13, PPC44x_TLB_XLAT /* Write XLAT */ /* * Create PAGEID. This is the faulting address, * page size, and valid flag. */ - li r11, PPC44x_TLB_VALID | PPC44x_TLB_4K + li r11, PPC44x_TLB_VALID | PPC44x_TLB_SIZE rlwimi r10, r11, 0, 20, 31 /* Insert valid and page size */ tlbwe r10, r13, PPC44x_TLB_PAGEID /* Write PAGEID */
@@ -740,12 +741,12 @@ _GLOBAL(set_context) * goes at the beginning of the data segment, which is page-aligned. */ .data - .align 12 + .align PAGE_SHIFT .globl sdata sdata: .globl empty_zero_page empty_zero_page: - .space 4096 + .space PAGE_SIZE /* * To support >32-bit physical addresses, we use an 8KB pgdir.
arch/ppc/kernel/misc.S +7 -6
@@ -17,6 +17,7 @@ #include <asm/errno.h> #include <asm/processor.h> #include <asm/page.h> +#include <asm/ppc_page_asm.h> #include <asm/cache.h> #include <asm/cputable.h> #include <asm/mmu.h>
@@ -473,8 +474,8 @@ _GLOBAL(__flush_dcache_icache) BEGIN_FTR_SECTION blr /* for 601, do nothing */ END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE) - rlwinm r3,r3,0,0,19 /* Get page base address */ - li r4,4096/L1_CACHE_BYTES /* Number of lines in a page */ + rlwinm r3,r3,0,0,PPC44x_RPN_M2 /* Get page base address */ + li r4,PAGE_SIZE/L1_CACHE_BYTES /* Number of lines in a page */ mtctr r4 mr r6,r3 0: dcbst 0,r3 /* Write line to ram */
@@ -505,8 +506,8 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE) rlwinm r0,r10,0,28,26 /* clear DR */ mtmsr r0 isync - rlwinm r3,r3,0,0,19 /* Get page base address */ - li r4,4096/L1_CACHE_BYTES /* Number of lines in a page */ + rlwinm r3,r3,0,0,PPC44x_RPN_M2 /* Get page base address */ + li r4,PAGE_SIZE/L1_CACHE_BYTES /* Number of lines in a page */ mtctr r4 mr r6,r3 0: dcbst 0,r3 /* Write line to ram */
@@ -530,7 +531,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE) * void clear_pages(void *page, int order) ; */ _GLOBAL(clear_pages) - li r0,4096/L1_CACHE_BYTES + li r0,PAGE_SIZE/L1_CACHE_BYTES slw r0,r0,r4 mtctr r0 #ifdef CONFIG_8xx
@@ -588,7 +589,7 @@ _GLOBAL(copy_page) dcbt r5,r4 li r11,L1_CACHE_BYTES+4 #endif /* MAX_COPY_PREFETCH */ - li r0,4096/L1_CACHE_BYTES - MAX_COPY_PREFETCH + li r0,PAGE_SIZE/L1_CACHE_BYTES - MAX_COPY_PREFETCH crclr 4*cr0+eq 2: mtctr r0
arch/ppc/kernel/vmlinux.lds.S +8 -7
@@ -1,4 +1,5 @@ #include <asm-generic/vmlinux.lds.h> +#include <asm/page.h> OUTPUT_ARCH(powerpc:common) jiffies = jiffies_64 + 4;
@@ -64,7 +65,7 @@ SECTIONS } /* Read-write section, merged into data segment: */ - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); .data : { *(.data)
@@ -76,10 +77,10 @@ SECTIONS CONSTRUCTORS } - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); __nosave_begin = .; .data_nosave : { *(.data.nosave) } - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); __nosave_end = .; . = ALIGN(32);
@@ -91,7 +92,7 @@ SECTIONS . = ALIGN(8192); .data.init_task : { *(.data.init_task) } - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); __init_begin = .; .init.text : { _sinittext = .;
@@ -136,16 +137,16 @@ SECTIONS __per_cpu_end = .; #ifdef CONFIG_BLK_DEV_INITRD - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); __initramfs_start = .; .init.ramfs : { *(.init.ramfs) } __initramfs_end = .; #endif - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); __init_end = .; - . = ALIGN(4096); + . = ALIGN(PAGE_SIZE); _sextratext = .; _eextratext = .;
include/asm-ppc/page.h +5 -1
@@ -4,7 +4,7 @@#include <asm/asm-compat.h> /* PAGE_SHIFT determines the page size */ -#define PAGE_SHIFT 12 +#define PAGE_SHIFT CONFIG_PPC_PAGE_SHIFT#define PAGE_SIZE (ASM_CONST(1) << PAGE_SHIFT)/*
@@ -28,7 +28,11 @@*/ #ifdef CONFIG_PTE_64BIT typedef unsigned long long pte_basic_t ; +#if (PAGE_SHIFT ==16 ) && defined(CONFIG_PPC32 ) +#define PTE_SHIFT (PAGE_SHIFT - 11)/* 256 ptes per table*/ +#else #define PTE_SHIFT (PAGE_SHIFT - 3)/* 512 ptes per page */ +#endif #define PTE_FMT "%16Lx"#else typedef unsigned long pte_basic_t ;
include/asm-ppc/ppc_page_asm.h new file +49 -0
49 lines not on this page · raw message
Quoted 9 lines · Stefan Roese
arch/ppc/Kconfig +9
-0+config PPC_PAGE_SHIFT + int "Page size (12=>4KB; 16=>64KB)" + default "12" + range 12 16 + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + + If unsure, set it to 12 (4KB).
[snip]
include/asm-ppc/ppc_page_asm.h line 47
Quoted 3 lines
include/asm-ppc/ppc_page_asm.h new file +3
-0+#else +#error "Unsupported PAGE_SIZE" +#endif
If you only support 4k and 64k page sizes, why do you let the user choose 13, 14 or 15 for PPC_PAGE_SHIFT? Why not just have a "64k pages" boolean option like 64-bit powerpc does?
Paul.
Quoted 14 lines · Paul Mackerras
Quoted 9 lines · Stefan Roese
arch/ppc/Kconfig +9
-0+config PPC_PAGE_SHIFT + int "Page size (12=>4KB; 16=>64KB)" + default "12" + range 12 16 + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + + If unsure, set it to 12 (4KB).[snip]
Quoted 7 lines
include/asm-ppc/ppc_page_asm.h line 47
Quoted 3 lines
include/asm-ppc/ppc_page_asm.h new file +3
-0+#else +#error "Unsupported PAGE_SIZE" +#endif If you only support 4k and 64k page sizes, why do you let the user choose 13, 14 or 15 for
PPC_PAGE_SHIFT? Why not just have a "64k pages" boolean option like 64-bit powerpc does?
As far as I can tell from the patch, 14 should work too (16kB pages). 13 or 15 won't, since only power-of-4 pagesizes are supported on 44x.
Signature · 4 lines
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
Quoted 12 lines · Stefan Roese
This patch adds support for the
PAGE_SIZEset equal to 64 KB on PPC32 platforms. Increasing thePAGE_SIZEmay improve the performance of the system in some cases.The RAID processing with the dedicated hardware that offloads the CPU is one of such cases. Using the bigger
PAGE_SIZEwe decrease the number of CPU operations required to process the data blocks, decrease the control overheads and so improve the overall performance. For example, changing thePAGE_SIZEfrom 4KB to 64KB on a Yucca (440SPe) gives ~300% performance benefit of the full-stripe writing in the (7d+1p) RAID-5 setup.
Quoted 3 lines
Signed-off-by Yuri Tikhonov <[email protected]>Acked-by Wolfgang Denk <[email protected]>Acked-by Stefan Roese <[email protected]>
While it's a good idea, there are a couple of issues with the patch:
- It's arch/ppc. We shouldn't do new major features on this codebase.
You are welcome however in helping moving over 4xx to arch/powerpc :-)
- You only adapted head_4xx.S but the config option is global to all ofarch/ppc, thus changing it will probably break everything else. Make sure the option is done in such a way that it can't be changed or the kernel doesn't build if changed for a processor family where you haven't implemented the support
- Have you tried other page sizes ? How hard would it be to support 16K
and what kind of performance numbers do you get with 16K ? It's a better compromise for some applications as 64K causes significant bloat of the page cache (among other things).
Cheers,
Ben.
Quoted 4 lines · Benjamin Herrenschmidt
While it's a good idea, there are a couple of issues with the patch:
- It's
arch/ppc. We shouldn't do new major features on this codebase.
You are welcome however in helping moving over 4xx toarch/powerpc:-)
Yes, sure. But the project this patch was developed for started quite a while ago when absolutely no 4xx support was available in arch/powerpc. I'm of course aware that we have to move to arch/powerpc in the near future and am willing to help here.
Quoted 5 lines
- You only adapted
head_4xx.Sbut the config option is global to all ofarch/ppc, thus changing it will probably break everything else. Make sure the option is done in such a way that it can't be changed or the kernel doesn't build if changed for a processor family where you haven't implemented the support
OK, will address this problem later.
Quoted 4 lines
- Have you tried other page sizes ? How hard would it be to support 16K
and what kind of performance numbers do you get with 16K ? It's a better compromise for some applications as 64K causes significant bloat of the page cache (among other things).
No, we haven't tested other page sizes. We chose 64K because it is the stripe size of the RAID arrays.
Thanks.
Best regards,
Stefan
Dear Ben,
Quoted 3 lines · in message <[email protected]> you wrote:
- It's
arch/ppc. We shouldn't do new major features on this codebase.
You are welcome however in helping moving over 4xx toarch/powerpc:-)
Will do that as soon as we have an arch/powerpc port for the 440SP / 440SPe
Quoted 2 lines
- You only adapted
head_4xx.Sbut the config option is global to all ofarch/ppc, thus changing it will probably break everything else. Make
You are probably right. We will try to clean this up.
Quoted 2 lines
- Have you tried other page sizes ? How hard would it be to support 16K
and what kind of performance numbers do you get with 16K ? It's a better
16 kB should work, but was not tested so far. From our RAID oriented calculations it's not interesting.
We tried 256 kB, but kernel linking fails with a "Not enough room for program headers" error message. We will investigate this ASAP, but at the moment we have other priorities. [Any hints what might go wrong are welcome.]
Quoted 2 lines
compromise for some applications as 64K causes significant bloat of the page cache (among other things).
Agreed, but this obviously depends on the sort of application(s) you're running.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] I'd like to meet the man who invented sex and see what he's working on now.
Quoted 9 lines · Wolfgang Denk
Dear Ben,
Quoted 3 lines · in message <[email protected]> you wrote:
- It's
arch/ppc. We shouldn't do new major features on this codebase.
You are welcome however in helping moving over 4xx toarch/powerpc:-)Will do that as soon as we have an
arch/powerpcport for the 440SP / 440SPe
Ah great. I was thinking about working on 440GX after I'm back from the ski. (I have a Taishan board)
We'll need to look into the MSI problem for SPe I suppose too... hopefully Michael should have a proper MSI core merged upstream soom (/me crosses fingers).
Quoted 5 lines
Quoted 2 lines
- Have you tried other page sizes ? How hard would it be to support 16K
and what kind of performance numbers do you get with 16K ? It's a better16 kB should work, but was not tested so far. From our RAID oriented calculations it's not interesting.
Fair enough. I still think it would be useful for other workloads to have that choice though :-)
Quoted 4 lines
We tried 256 kB, but kernel linking fails with a "Not enough room for program headers" error message. We will investigate this ASAP, but at the moment we have other priorities. [Any hints what might go wrong are welcome.]
256K will not be doable without serious hacking afaik. Anything above 64K. You won't be able to run most userland apps for example as the sections are generally 64K aligned.
Quoted 2 lines
Agreed, but this obviously depends on the sort of application(s) you're running.
Definitely.
Cheers,
Ben.
Quoted 6 lines · Stefan Roese
arch/ppc/Kconfig | 10 ++++++++ arch/ppc/kernel/head_44x.S | 23 ++++++++++--------- arch/ppc/kernel/misc.S | 13 ++++++----- arch/ppc/kernel/vmlinux.lds.S | 15 +++++++----- include/asm-ppc/page.h | 6 ++++- include/asm-ppc/ppc_page_asm.h | 49 ++++++++++++++++++++++++++++++++++++++++
I though we'd given up on arch/ppc by now?
Can you try to redo this over the arch/powerpc/ 44x port?
Quoted 10 lines · Christoph Hellwig
Quoted 6 lines · Stefan Roese
arch/ppc/Kconfig | 10 ++++++++ arch/ppc/kernel/head_44x.S | 23 ++++++++++--------- arch/ppc/kernel/misc.S | 13 ++++++----- arch/ppc/kernel/vmlinux.lds.S | 15 +++++++----- include/asm-ppc/page.h | 6 ++++- include/asm-ppc/ppc_page_asm.h | 49 ++++++++++++++++++++++++++++++++++++++++I though we'd given up on
arch/ppcby now?
Can you try to redo this over thearch/powerpc/44x port?
The arch/powerpc 44x port is hardly complete yet...
Signature · 4 lines
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
Quoted 10 lines · Christoph Hellwig
Quoted 6 lines · Stefan Roese
arch/ppc/Kconfig | 10 ++++++++ arch/ppc/kernel/head_44x.S | 23 ++++++++++--------- arch/ppc/kernel/misc.S | 13 ++++++----- arch/ppc/kernel/vmlinux.lds.S | 15 +++++++----- include/asm-ppc/page.h | 6 ++++- include/asm-ppc/ppc_page_asm.h | 49 ++++++++++++++++++++++++++++++++++++++++I though we'd given up on
arch/ppcby now?
Can you try to redo this over thearch/powerpc/44x port?
Not dead yet. arch/powerpc support is not complete for 4xx cores and older bootloaders cannot boot arch/powerpc kernels yet.
g.
Signature · 4 lines
Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. [email protected] (403) 399-0195
Quoted 9 lines · Grant Likely
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Stefan Roese
arch/ppc/Kconfig | 10 ++++++++ arch/ppc/kernel/head_44x.S | 23 ++++++++++--------- arch/ppc/kernel/misc.S | 13 ++++++----- arch/ppc/kernel/vmlinux.lds.S | 15 +++++++----- include/asm-ppc/page.h | 6 ++++- include/asm-ppc/ppc_page_asm.h | 49 ++++++++++++++++++++++++++++++++++++++++
Quoted 5 lines
Quoted 2 lines
I though we'd given up on
arch/ppcby now?
Can you try to redo this over thearch/powerpc/44x port?Not dead yet.
arch/powerpcsupport is not complete for 4xx cores and older bootloaders cannot bootarch/powerpckernels yet.
Um, yes they can. You just need to include the dtb in the zImage wrapper. I've booted Ebony with Openbios using David's patches and Bamboo with PIBS using my patches (which are based off David's patches).
What I think you mean is that there is no translation from a bd_t (using older u-boot for example) to a dt in the wrapper yet. But that is what Scott's cuimage patches are for.
josh
Quoted 2 lines · Stefan Roese
This patch adds support for the
PAGE_SIZEset equal to 64 KB on PPC32 platforms.
If I'm reading the patch right, with 64k pages you're using 8kB pgd arrays and 256-byte pte arrays, so you're only using 1/256th of each PTE page. In fact each PTE page could map 512MB (assuming 8 byte ptes), and the pgd array could be a tiny 8-entry thing, which we could kmalloc. I think that would use memory more efficiently.
Paul.