Skip to contentSkip to conversation

ppc44x: support for 256K PAGE_SIZE

PATCH In review Yuri Tikhonov 7 participants 22 messages Oct 18, 2007 – Oct 23, 2007

lore
Share & tools
lore

Yuri Tikhonov

author
#0 lore raw

PATCH 1/1 ppc44x: support for 256K PAGE_SIZE

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 0x40000 (as opposite to standard 0x10000).

Signed-off-by Pavel Kolesnikov <[email protected]>
Acked-by Yuri Tikhonov <[email protected]>

--

arch/ppc/Kconfig +3 -0
index c590b18..0ee372d 100644
@@ -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
arch/ppc/kernel/entry.S +3 -3
index fba7ca1..2140341 100644
@@ -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

arch/ppc/kernel/head_booke.h +6 -2
index f3d274c..db4eeee 100644
@@ -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   */\
-	addi	r1,r1,THREAD_SIZE;					     \
+	lis	r11,THREAD_SIZE@h;                                           \
+	ori	r11,r11,THREAD_SIZE@l;					     \
+	add     r1,r1,r11;						     \
 1:	subi	r1,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 */\
-	addi	r11,r11,THREAD_SIZE;					     \
+	lis     r11,THREAD_SIZE@h;					     \
+	ori     r11,r11,THREAD_SIZE@l;					     \
+	add     r1,r1,r11;						     \
 1:	subi	r11,r11,INT_FRAME_SIZE;	/* Allocate an exception frame     */\
 	stw	r10,_CCR(r11);          /* save various registers	   */\
 	stw	r12,GPR12(r11);						     \
(quoted diff) +0 -0

b/include/asm-powerpc/thread_info.h
index 3f32ca8..0a564ce 100644

include/asm-powerpc/thread_info.h +22 -3
@@ -15,7 +15,11 @@
 #ifdef CONFIG_PPC64
 #define THREAD_SHIFT		14
 #else
-#define THREAD_SHIFT		13
+#if defined(CONFIG_PPC_PAGE_256K)
+#define THREAD_SHIFT		15
+#else
+#define THREAD_SHIFT		13
+#endif
 #endif
 
 #define THREAD_SIZE		(1 << THREAD_SHIFT)

@@ -81,11 +85,26 @@ struct thread_info {
 #else /* THREAD_SHIFT < PAGE_SHIFT */
 
 #ifdef CONFIG_DEBUG_STACK_USAGE
-#define alloc_thread_info(tsk)	kzalloc(THREAD_SIZE, GFP_KERNEL)
+#if defined(CONFIG_PPC_PAGE_256K)
+#define alloc_thread_info(tsk)	\
+	((struct thread_info *)__get_free_pages(GFP_KERNEL |	\
+			__GFP_ZERO, 0))
 #else
-#define alloc_thread_info(tsk)	kmalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) kzalloc(THREAD_SIZE, GFP_KERNEL)
 #endif
+#else /* CONFIG_DEBUG_STACK_USAGE */
+#if defined(CONFIG_PPC_PAGE_256K)
+#define alloc_thread_info(tsk)	\
+	((struct thread_info *)__get_free_pages(GFP_KERNEL, 0))
+#else
+#define alloc_thread_info(tsk)	kmalloc(THREAD_SIZE, GFP_KERNEL)
+#endif
+#endif /* CONFIG_DEBUG_STACK_USAGE */
+#if defined(CONFIG_PPC_PAGE_256K)
+#define free_thread_info(ti)	free_pages((unsigned long)ti, 0)
+#else
 #define free_thread_info(ti)	kfree(ti)
+#endif
 
 #endif /* THREAD_SHIFT < PAGE_SHIFT */
include/asm-ppc/page.h +6 -0
index cb4a484..726823b 100644
@@ -10,6 +10,8 @@
 #define PAGE_SHIFT	14
 #elif defined(CONFIG_PPC_PAGE_64K)
 #define PAGE_SHIFT	16
+#elif defined(CONFIG_PPC_PAGE_256K)
+#define PAGE_SHIFT	18
 #endif
 #define PAGE_SIZE	(ASM_CONST(1) << PAGE_SHIFT)
 

@@ -34,7 +36,11 @@
  */
 #ifdef CONFIG_PTE_64BIT
 typedef unsigned long long pte_basic_t;
+#if defined(CONFIG_PPC_PAGE_256K)
+#define PTE_SHIFT	(PAGE_SHIFT - 7)
+#else
 #define PTE_SHIFT	(PAGE_SHIFT - 3)	/* PAGE_SIZE/8 ptes per page */
+#endif
 #define PTE_FMT		"%16Lx"
 #else
 typedef unsigned long pte_basic_t;
include/asm-ppc/ppc_page_asm.h +13 -0
index 1dbfd3b..924463c 100644
@@ -55,6 +55,19 @@
 #define PPC44x_PTE_ADD_SH	19 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/
 #define PPC44x_PTE_ADD_M1	16 /*32 - 3 - PTE_SHIFT*/
 #define PPC44x_RPN_M2		15 /*31 - PAGE_SHIFT*/
+#elif (PAGE_SHIFT == 18)
+/*
+ * PAGE_SIZE  256K
+ * PAGE_SHIFT 18
+ * PTE_SHIFT  11
+ * PMD_SHIFT  29
+ */
+#define PPC44x_TLB_SIZE	PPC44x_TLB_256K
+#define PPC44x_PGD_OFF_SH	5  /*(32 - PMD_SHIFT + 2)*/
+#define PPC44x_PGD_OFF_M1	27 /*(PMD_SHIFT - 2)*/
+#define PPC44x_PTE_ADD_SH	17 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/
+#define PPC44x_PTE_ADD_M1	18 /*32 - 3 - PTE_SHIFT*/
+#define PPC44x_RPN_M2		13 /*31 - PAGE_SHIFT*/
 #else
 #error "Unsupported PAGE_SIZE"
 #endif
arch/ppc/kernel/vmlinux.lds.S +9 -3
index 930fe30..3ba570b 100644
@@ -3,6 +3,11 @@
 
 OUTPUT_ARCH(powerpc:common)
 jiffies = jiffies_64 + 4;
+PHDRS
+{
+ text PT_LOAD FILEHDR PHDRS FLAGS (7);
+ data PT_LOAD FLAGS (7);
+}
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */

@@ -30,6 +35,7 @@ SECTIONS
   .rela.plt      : { *(.rela.plt)		}
 /*  .init          : { *(.init)	} =0*/
   .plt : { *(.plt) }
+  . = ALIGN(PAGE_SIZE);
   .text      :
   {
     _text = .;

@@ -41,7 +47,7 @@ SECTIONS
     __got2_start = .;
     *(.got2)
     __got2_end = .;
-  }
+  } :text
   _etext = .;
   PROVIDE (etext = .);
 

@@ -75,7 +81,7 @@ SECTIONS
     *(.got.plt) *(.got)
     *(.dynamic)
     CONSTRUCTORS
-  }
+  } :data
 
   . = ALIGN(PAGE_SIZE);
   __nosave_begin = .;

@@ -89,7 +95,7 @@ SECTIONS
   _edata  =  .;
   PROVIDE (edata = .);
 
-  . = ALIGN(8192);
+  . = ALIGN(PAGE_SIZE << 1);
   .data.init_task : { *(.data.init_task) }
 
   . = ALIGN(PAGE_SIZE);
Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#1 lore raw
Quoted 6 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

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

#2 lore raw
Quoted 11 lines · Josh Boyer
Quoted 6 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

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.

#3 lore raw
Quoted 10 lines · On Thu, 18 Oct 2007 21:45:14 +1000 Benjamin Herrenschmidt…
Quoted 8 lines · Josh Boyer
Quoted 6 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

Quoted 8 lines
Quoted 3 lines

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?

Quoted 7 lines

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

#4 lore raw
Quoted 17 lines · Josh Boyer
Quoted 14 lines · On Thu, 18 Oct 2007 21:45:14 +1000 Benjamin Herrenschmidt…
Quoted 11 lines · Josh Boyer
Quoted 6 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 5 lines
Quoted 5 lines

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.

Quoted 8 lines
Quoted 2 lines

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.

author
#5 lore raw
Quoted 9 lines · Benjamin Herrenschmidt
Quoted 3 lines

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).

Quoted 4 lines

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.

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#6 lore raw
In reply to Josh Boyer
Quoted 1 line

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

author
#7 lore raw
In reply to Josh Boyer
Quoted 2 lines · you

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.

Quoted 1 line

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.

Quoted 1 line

josh

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#8 lore raw
Quoted 8 lines · On Thu, 18 Oct 2007 17:18:00 +0400 Yuri Tikhonov <[email protected]> wrote:
Quoted 2 lines · you

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?

Quoted 4 lines
Quoted 1 line

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

author
#9 lore raw
Quoted 5 lines · Josh Boyer
Quoted 3 lines

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).

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 3 lines

josh

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#10 lore raw
Quoted 8 lines · On Thu, 18 Oct 2007 17:30:17 +0400 Yuri Tikhonov <[email protected]> wrote:
Quoted 5 lines · Josh Boyer
Quoted 3 lines

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.

Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines

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

#11 lore raw
In reply to Yuri Tikhonov
Quoted 4 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

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.

#12 lore raw
Quoted 9 lines · Paul Mackerras
Quoted 4 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

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

author
#13 lore raw
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Paul Mackerras
Quoted 6 lines · Yuri Tikhonov

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 0x40000 (as opposite to standard 0x10000).

Quoted 5 lines
Quoted 2 lines

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 (0x10000) or larger powers of 2...".

So, 256 Kbytes is just a larger case.

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#14 lore raw
Quoted 13 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

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 0x40000 (as opposite to standard 0x10000).

Quoted 5 lines
Quoted 2 lines

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?

Quoted 8 lines

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 (0x10000) 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

#15 lore raw
Quoted 4 lines · Segher Boessenkool

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.

#16 lore raw
In reply to Yuri Tikhonov
Quoted 6 lines · Yuri Tikhonov

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 (0x10000) 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.

author
#17 lore raw
In reply to Paul Mackerras
Quoted 2 lines · Paul Mackerras

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.

Quoted 2 lines

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.

Quoted 3 lines

Paul.

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#18 lore raw
Quoted 14 lines · Yuri Tikhonov
Quoted 2 lines · Paul Mackerras

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;

Quoted 8 lines

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?

Quoted 5 lines
Quoted 2 lines

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

author
#19 lore raw
Quoted 6 lines · Kumar Gala
Quoted 6 lines

PAGE_SIZE = 4K:
P = 66 MBps;

PAGE_SIZE = 16K:
P = 145 MBps;

Quoted 8 lines
Quoted 5 lines

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.

Signature · 2 lines
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
#20 lore raw
In reply to Yuri Tikhonov
Quoted 18 lines · On Thu, 18 Oct 2007 11:08:19 +0400 Yuri Tikhonov <[email protected]> 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 0x40000 (as opposite to standard 0x10000).

Signed-off-by Pavel Kolesnikov <[email protected]>
Acked-by Yuri Tikhonov <[email protected]>

--

arch/ppc/Kconfig +0 -0
index c590b18..0ee372d 100644

arch/ppc/Kconfig config PPC_PAGE_16K · line 1229

Quoted 7 lines
arch/ppc/Kconfig +3 -0
@@ -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

BTW, what tree did you base this on? I don't seem to have the PPC_PAGE_* options in my tree.

josh

#21 lore raw

Dear Josh,

Quoted 5 lines · in message <[email protected]> you wrote:
Quoted 5 lines

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 0x40000 (as opposite to standard 0x10000).

...

Quoted 3 lines

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%20sizes&id=10646

Best regards,

Wolfgang Denk

Signature · 5 lines
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.