Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
The following patch adds support for 256KB PAGE_SIZE on ppc44x- based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I was wondering about this as well? Isn't this technically in violation of the ABI? No it isn't the violation. As stated in System V ABI. PowerPC processor supplement (on which the Linux Standard Base Core Specification for PPC32 is based): ... Virtual addresses and file offsets for the PowerPC processor family segments are congruent modulo 64 Kbytes (0x1) or larger powers of 2 So, 256 Kbytes is just a larger case. If I understand you correctly, the only problem with existing binaries is that the ELF segments are aligned to 64kB, but not necessarily to 256kB. Couldn't you handle this as a special case, for example by mapping the ends of such an unaligned segment with normal 4kB pages? That way, a new binutils isn't required to get a big part of the benefit, and importantly, existing shared library binaries will work with your apps. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Requiring a modified binutils makes me a bit nervous though. As long as those binutils modifications are sent upstream, I don't see the problem? If not, this would be a blocker IMHO. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Segher Boessenkool writes: If I understand you correctly, the only problem with existing binaries is that the ELF segments are aligned to 64kB, but not necessarily to 256kB. Couldn't you handle this as a special case, for example by mapping the ends of such an unaligned segment with normal 4kB pages? That's very hard to do if the system page size is 256k, since the kernel has no support for mapping parts of pages. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Yuri Tikhonov writes: No it isn't the violation. As stated in System V ABI. PowerPC processor supplement (on which the Linux Standard Base Core Specification for PPC32 is based): ... Virtual addresses and file offsets for the PowerPC processor family segments are congruent modulo 64 Kbytes (0x1) or larger powers of 2 I'm afraid it is a violation. In the Operating System Interface chapter, Page Size section (page 3-23 in the copy I have), it says: Currently, the only valid hardware page size for the PowerPC Architecture is 4096 bytes (4 Kbytes), but this ABI allows the underlying operating system to cluster pages into logical power-of-two page sizes up to 65536 bytes (64 Kbytes). The section you quoted says that ELF binaries may use a larger congruency, not that the OS may use a larger page size. In fact the largest page size that the OS may use is the *smallest* congruency that ELF binaries may use. Of course, nothing says that you can't use kernels and binaries that are not SVR4-compliant on your own machines. But not being SVR4-compliant certainly limits their general usefulness. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Friday 19 October 2007 17:24, Kumar Gala wrote: On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote: Yuri Tikhonov writes: The following patch adds support for 256KB PAGE_SIZE on ppc44x- based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I was wondering about this as well? Isn't this technically in violation of the ABI? No it isn't the violation. As stated in System V ABI. PowerPC processor supplement (on which the Linux Standard Base Core Specification for PPC32 is based): ... Virtual addresses and file offsets for the PowerPC processor family segments are congruent modulo 64 Kbytes (0x1) or larger powers of 2 So, 256 Kbytes is just a larger case. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Dear Josh, in message [EMAIL PROTECTED] you wrote: The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). ... BTW, what tree did you base this on? I don't seem to have the PPC_PAGE_* options in my tree. If you like to see the patches in context, you can find this stuff in the linux-2.6-denx repository at denx.de The 256K page size stuff is based on and requires as prerequisite the ppc: Add support for bigger page sizes than 4KB on PPC44x posted here on April 25, see http://patchwork.ozlabs.org/linuxppc/patch?q=Add%20support%20for%20bigger%20page%20sizesid=10646 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Oct 19, 2007, at 10:37 AM, Yuri Tikhonov wrote: On Friday 19 October 2007 03:21, Paul Mackerras wrote: Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I measured the performance of the sequential full-stripe write operations to a RAID-5 array (P values below are in MB per second) using the h/w accelerated RAID-5 driver. Here are the comparative results for the different PAGE_SIZE values: PAGE_SIZE = 4K: P = 66 MBps; PAGE_SIZE = 16K: P = 145 MBps; PAGE_SIZE = 64K: P = 196 MBps; PAGE_SIZE = 256K: P = 217 MBps. Is this all in kernel space? or is there a user space aspect to the benchmark? The 64kB page size has the attraction that no binutils changes are required. That's true, but the additional performance is an attractive thing too. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote: Yuri Tikhonov writes: The following patch adds support for 256KB PAGE_SIZE on ppc44x- based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I was wondering about this as well? Isn't this technically in violation of the ABI? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Friday 19 October 2007 03:21, Paul Mackerras wrote: Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I measured the performance of the sequential full-stripe write operations to a RAID-5 array (P values below are in MB per second) using the h/w accelerated RAID-5 driver. Here are the comparative results for the different PAGE_SIZE values: PAGE_SIZE = 4K: P = 66 MBps; PAGE_SIZE = 16K: P = 145 MBps; PAGE_SIZE = 64K: P = 196 MBps; PAGE_SIZE = 256K: P = 217 MBps. The 64kB page size has the attraction that no binutils changes are required. That's true, but the additional performance is an attractive thing too. Paul. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Friday 19 October 2007 19:48, Kumar Gala wrote: PAGE_SIZE = 4K: P = 66 MBps; PAGE_SIZE = 16K: P = 145 MBps; PAGE_SIZE = 64K: P = 196 MBps; PAGE_SIZE = 256K: P = 217 MBps. Is this all in kernel space? or is there a user space aspect to the benchmark? The situation here is that the Linux RAID driver does a lot of complex things with the pages (strips of array) using CPU before submitting these pages to h/w. Here is where the most time is spent. Thus, increasing the PAGE_SIZE value we reduce the number of these complex algorithms calls needed to process the whole test (writing the fixed number of MBytes to RAID array). So, there are no user space aspects. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 2007-10-18 at 11:08 +0400, Yuri Tikhonov wrote: Hello, The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Also, I'd rather see something along the lines of hugetlbfs support instead. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
It has turned out that my mailer had corrupted my previous message (thanks Wolfgang Denk for pointing this). So if you'd like to apply the patch without the conflicts please use the version of the patch in this mail. The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Signed-off-by: Pavel Kolesnikov [EMAIL PROTECTED] Acked-by: Yuri Tikhonov [EMAIL PROTECTED] -- diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig index c590b18..0ee372d 100644 --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -1223,6 +1223,9 @@ config PPC_PAGE_16K config PPC_PAGE_64K bool 64 KB if 44x + +config PPC_PAGE_256K + bool 256 KB if 44x endchoice endmenu diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S index fba7ca1..2140341 100644 --- a/arch/ppc/kernel/entry.S +++ b/arch/ppc/kernel/entry.S @@ -200,7 +200,7 @@ _GLOBAL(DoSyscall) #ifdef SHOW_SYSCALLS bl do_show_syscall #endif /* SHOW_SYSCALLS */ - rlwinm r10,r1,0,0,18 /* current_thread_info() */ + rlwinm r10,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ lwz r11,TI_FLAGS(r10) andi. r11,r11,_TIF_SYSCALL_T_OR_A bne-syscall_dotrace @@ -221,7 +221,7 @@ ret_from_syscall: bl do_show_syscall_exit #endif mr r6,r3 - rlwinm r12,r1,0,0,18 /* current_thread_info() */ + rlwinm r12,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ /* disable interrupts so current_thread_info()-flags can't change */ LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */ SYNC @@ -639,7 +639,7 @@ ret_from_except: user_exc_return: /* r10 contains MSR_KERNEL here */ /* Check current_thread_info()-flags */ - rlwinm r9,r1,0,0,18 + rlwinm r9,r1,0,0,(31-THREAD_SHIFT) lwz r9,TI_FLAGS(r9) andi. r0,r9,(_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK|_TIF_NEED_RESCHED) bne do_work @@ -659,7 +659,7 @@ restore_user: /* N.B. the only way to get here is from the beq following ret_from_except. */ resume_kernel: /* check current_thread_info-preempt_count */ - rlwinm r9,r1,0,0,18 + rlwinm r9,r1,0,0,(31-THREAD_SHIFT) lwz r0,TI_PREEMPT(r9) cmpwi 0,r0,0 /* if non-zero, just restore regs and return */ bne restore @@ -669,7 +669,7 @@ resume_kernel: andi. r0,r3,MSR_EE/* interrupts off? */ beq restore /* don't schedule if so */ 1: bl preempt_schedule_irq - rlwinm r9,r1,0,0,18 + rlwinm r9,r1,0,0,(31-THREAD_SHIFT) lwz r3,TI_FLAGS(r9) andi. r0,r3,_TIF_NEED_RESCHED bne-1b @@ -875,7 +875,7 @@ recheck: LOAD_MSR_KERNEL(r10,MSR_KERNEL) SYNC MTMSRD(r10) /* disable interrupts */ - rlwinm r9,r1,0,0,18 + rlwinm r9,r1,0,0,(31-THREAD_SHIFT) lwz r9,TI_FLAGS(r9) andi. r0,r9,_TIF_NEED_RESCHED bne-do_resched diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h index f3d274c..db4 100644 --- a/arch/ppc/kernel/head_booke.h +++ b/arch/ppc/kernel/head_booke.h @@ -20,7 +20,9 @@ beq 1f; \ mfspr r1,SPRN_SPRG3; /* if from user, start at top of */\ lwz r1,THREAD_INFO-THREAD(r1); /* this thread's kernel stack */\ - addir1,r1,THREAD_SIZE; \ + lis r11,[EMAIL PROTECTED]; \ + ori r11,r11,[EMAIL PROTECTED]; \ + add r1,r1,r11; \ 1: subir1,r1,INT_FRAME_SIZE; /* Allocate an exception frame */\ mr r11,r1; \ stw r10,_CCR(r11); /* save various registers */\ @@ -106,7 +108,9 @@ /* COMING FROM USER MODE */ \ mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\ lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\ - addir11,r11,THREAD_SIZE; \ + lis r11,[EMAIL PROTECTED]; \ + ori r11,r11,[EMAIL PROTECTED]; \ + add r1,r1,r11; \ 1: subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ stw r10,_CCR(r11); /* save various registers */\ stw
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 2007-10-18 at 05:44 -0500, Josh Boyer wrote: On Thu, 2007-10-18 at 11:08 +0400, Yuri Tikhonov wrote: Hello, The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Also, I'd rather see something along the lines of hugetlbfs support instead. I slightly disagree on that one. It does make sense in embedded applications to use larger page sizes like that to compensate for small TLBs, and hugetlbfs has serious constraints that may well make it impractical. Based on that, I'd be tempted to let that in provided it doesn't requires ugly hacks, which seems to be the case. It still needs to be adapted to arch/powerpc however, and get closer scrutiny that I didn't have time to do yet. You are the maintainer, so you decide, but my opinion here is that wanting that is fair enough. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 2007-10-18 at 15:00 +0400, Yuri Tikhonov wrote: It has turned out that my mailer had corrupted my previous message (thanks Wolfgang Denk for pointing this). So if you'd like to apply the patch without the conflicts please use the version of the patch in this mail. The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Signed-off-by: Pavel Kolesnikov [EMAIL PROTECTED] Acked-by: Yuri Tikhonov [EMAIL PROTECTED] Small nit... You are posting the patch, thus you should be signing off, not ack'ing. Ack'ing means you agree with the patch but you aren't in the handling chain for it. In this case, it seems like the author is Pavel and you are forwarding it, in wich case, you -are- in the handling chain and should should sign it off. Best would be for Pavel (if he is indeed the author) to submit it himself though. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 18 Oct 2007 21:45:14 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2007-10-18 at 05:44 -0500, Josh Boyer wrote: On Thu, 2007-10-18 at 11:08 +0400, Yuri Tikhonov wrote: Hello, The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Also, I'd rather see something along the lines of hugetlbfs support instead. I slightly disagree on that one. It does make sense in embedded applications to use larger page sizes like that to compensate for small TLBs, and hugetlbfs has serious constraints that may well make it impractical. Out of curiosity, what constraints are those? Based on that, I'd be tempted to let that in provided it doesn't requires ugly hacks, which seems to be the case. It still needs to be adapted to arch/powerpc however, and get closer scrutiny that I didn't have time to do yet. You are the maintainer, so you decide, but my opinion here is that wanting that is fair enough. I always reserve the right to change my mind. If something makes sense and the code is decent enough then it might very well be acceptable. Requiring a modified binutils makes me a bit nervous though. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 2007-10-18 at 07:01 -0500, Josh Boyer wrote: On Thu, 18 Oct 2007 21:45:14 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2007-10-18 at 05:44 -0500, Josh Boyer wrote: On Thu, 2007-10-18 at 11:08 +0400, Yuri Tikhonov wrote: Hello, The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Also, I'd rather see something along the lines of hugetlbfs support instead. I slightly disagree on that one. It does make sense in embedded applications to use larger page sizes like that to compensate for small TLBs, and hugetlbfs has serious constraints that may well make it impractical. Out of curiosity, what constraints are those? You have to open map a specific file in specific areas, so you don't just get existing code build run with larger page size without change, there are various sneaky limitations here or there too, such as allocations more likely to fail etc... and in general, switching the base page size provides overall more performance improvement than just hacking an app to use hugetlbfs. Based on that, I'd be tempted to let that in provided it doesn't requires ugly hacks, which seems to be the case. It still needs to be adapted to arch/powerpc however, and get closer scrutiny that I didn't have time to do yet. You are the maintainer, so you decide, but my opinion here is that wanting that is fair enough. I always reserve the right to change my mind. If something makes sense and the code is decent enough then it might very well be acceptable. Requiring a modified binutils makes me a bit nervous though. From a kernel point of view, I totally don't care about the modified binutils to build userspace as long as it's not required to build the kernel and that option is not enabled by default (and explicitely documented as having that requirement). If it is necessary for building the kernel, then I'm a bit cooler about the whole thing indeed, the max page size needs to be added at least as a command line or linker script param so a different build of binutils isn't needed. My main base for judging is really how invasive/ugly the patch is. If it's neat and fits in without much damage, and serves a purpose, then there is no reason not to get it in. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thursday 18 October 2007 14:44, you wrote: Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Understood. The situation here is that the boards, which required these modifications, have no support in the arch/powerpc branch. So this is why we made this in arch/ppc. Also, I'd rather see something along the lines of hugetlbfs support instead. Here I agree with Benjamin. Furthermore, IIRC the hugetlb file-system is supported for PPC64 architectures only. Here we have PPC32. josh -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thursday 18 October 2007 15:47, Benjamin Herrenschmidt wrote: Signed-off-by: Pavel Kolesnikov [EMAIL PROTECTED] Acked-by: Yuri Tikhonov [EMAIL PROTECTED] Small nit... You are posting the patch, thus you should be signing off, not ack'ing. Ack'ing means you agree with the patch but you aren't in the handling chain for it. In this case, it seems like the author is Pavel and you are forwarding it, in wich case, you -are- in the handling chain and should should sign it off. Best would be for Pavel (if he is indeed the author) to submit it himself though. Thanks for the explanations. Will keep this in mind in the future. Ben. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thursday 18 October 2007 16:12, Benjamin Herrenschmidt wrote: I always reserve the right to change my mind. If something makes sense and the code is decent enough then it might very well be acceptable. Requiring a modified binutils makes me a bit nervous though. From a kernel point of view, I totally don't care about the modified binutils to build userspace as long as it's not required to build the kernel and that option is not enabled by default (and explicitely documented as having that requirement). If it is necessary for building the kernel, then I'm a bit cooler about the whole thing indeed, the max page size needs to be added at least as a command line or linker script param so a different build of binutils isn't needed. No, 256K-page-sized kernel is being built using the standard binutils. Modifications to them are necessary for user-space applications only. And the libraries as well. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thursday 18 October 2007 17:25, Josh Boyer wrote: Understood. The situation here is that the boards, which required these modifications, have no support in the arch/powerpc branch. So this is why we made this in arch/ppc. Bit of a dilemma then. What board exactly? These are the Katmai and Yucca PPC440SPe-based boards (from AMCC). Also, I'd rather see something along the lines of hugetlbfs support instead. Here I agree with Benjamin. Furthermore, IIRC the hugetlb file-system is supported for PPC64 architectures only. Here we have PPC32. Well that needs fixing anyway, but ok. Also, is the modified binutils only required for userspace to take advantage here? Seems so, but I'd just like to be sure. You are right, for userspace only. josh -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 18 Oct 2007 17:18:00 +0400 Yuri Tikhonov [EMAIL PROTECTED] wrote: On Thursday 18 October 2007 14:44, you wrote: Sorry, this is against arch/ppc which is bug fix only. New features should be done against arch/powerpc. Understood. The situation here is that the boards, which required these modifications, have no support in the arch/powerpc branch. So this is why we made this in arch/ppc. Bit of a dilemma then. What board exactly? Also, I'd rather see something along the lines of hugetlbfs support instead. Here I agree with Benjamin. Furthermore, IIRC the hugetlb file-system is supported for PPC64 architectures only. Here we have PPC32. Well that needs fixing anyway, but ok. Also, is the modified binutils only required for userspace to take advantage here? Seems so, but I'd just like to be sure. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Thu, 18 Oct 2007 17:30:17 +0400 Yuri Tikhonov [EMAIL PROTECTED] wrote: On Thursday 18 October 2007 17:25, Josh Boyer wrote: Understood. The situation here is that the boards, which required these modifications, have no support in the arch/powerpc branch. So this is why we made this in arch/ppc. Bit of a dilemma then. What board exactly? These are the Katmai and Yucca PPC440SPe-based boards (from AMCC). Hm... We should get those in. At this point in the kernel cycle, your patch would be 2.6.25 material anyway so perhaps there is some time to get Katmai and Yucca done by then. Also, I'd rather see something along the lines of hugetlbfs support instead. Here I agree with Benjamin. Furthermore, IIRC the hugetlb file-system is supported for PPC64 architectures only. Here we have PPC32. Well that needs fixing anyway, but ok. Also, is the modified binutils only required for userspace to take advantage here? Seems so, but I'd just like to be sure. You are right, for userspace only. Ok. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
Yuri Tikhonov writes: The following patch adds support for 256KB PAGE_SIZE on ppc44x-based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? The 64kB page size has the attraction that no binutils changes are required. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
