[PATCH] ppc44x: support for 256K PAGE_SIZE

[PATCH] ppc44x: support for 256K PAGE_SIZE

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

 Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
 Acked-by: Yuri Tikhonov <yur@emcraft.com>

--

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..db4eeee 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   */\
-	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);						     \
diff --git a/include/asm-powerpc/thread_info.h 
b/include/asm-powerpc/thread_info.h
index 3f32ca8..0a564ce 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -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 */
 
diff --git a/include/asm-ppc/page.h b/include/asm-ppc/page.h
index cb4a484..726823b 100644
--- a/include/asm-ppc/page.h
+++ b/include/asm-ppc/page.h
@@ -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;
diff --git a/include/asm-ppc/ppc_page_asm.h b/include/asm-ppc/ppc_page_asm.h
index 1dbfd3b..924463c 100644
--- a/include/asm-ppc/ppc_page_asm.h
+++ b/include/asm-ppc/ppc_page_asm.h
@@ -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
diff --git a/arch/ppc/kernel/vmlinux.lds.S b/arch/ppc/kernel/vmlinux.lds.S
index 930fe30..3ba570b 100644
--- a/arch/ppc/kernel/vmlinux.lds.S
+++ b/arch/ppc/kernel/vmlinux.lds.S
@@ -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);

 
-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Josh Boyer]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

 Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
 Acked-by: Yuri Tikhonov <yur@emcraft.com>

--

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..db4eeee 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   */\
-	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);						     \
diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h
index 3f32ca8..0a564ce 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -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 */
 
diff --git a/include/asm-ppc/page.h b/include/asm-ppc/page.h
index cb4a484..726823b 100644
--- a/include/asm-ppc/page.h
+++ b/include/asm-ppc/page.h
@@ -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;
diff --git a/include/asm-ppc/ppc_page_asm.h b/include/asm-ppc/ppc_page_asm.h
index 1dbfd3b..924463c 100644
--- a/include/asm-ppc/ppc_page_asm.h
+++ b/include/asm-ppc/ppc_page_asm.h
@@ -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
diff --git a/arch/ppc/kernel/vmlinux.lds.S b/arch/ppc/kernel/vmlinux.lds.S
index 930fe30..3ba570b 100644
--- a/arch/ppc/kernel/vmlinux.lds.S
+++ b/arch/ppc/kernel/vmlinux.lds.S
@@ -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);

-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Benjamin Herrenschmidt]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Benjamin Herrenschmidt]

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 0x40000 (as opposite to standard 0x10000).
> 
>  Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
>  Acked-by: Yuri Tikhonov <yur@emcraft.com>

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.

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Josh Boyer]

On Thu, 18 Oct 2007 21:45:14 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 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.

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Benjamin Herrenschmidt]

On Thu, 2007-10-18 at 07:01 -0500, Josh Boyer wrote:
> On Thu, 18 Oct 2007 21:45:14 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 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.
> 
> 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.

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

On Thursday 18 October 2007 15:47, Benjamin Herrenschmidt wrote:
> 
> >  Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
> >  Acked-by: Yuri Tikhonov <yur@emcraft.com>
> 
> 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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Josh Boyer]

On Thu, 18 Oct 2007 17:18:00 +0400
Yuri Tikhonov <yur@emcraft.com> 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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Josh Boyer]

On Thu, 18 Oct 2007 17:30:17 +0400
Yuri Tikhonov <yur@emcraft.com> 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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Paul Mackerras]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Kumar Gala]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Kumar Gala]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Josh Boyer]

On Thu, 18 Oct 2007 11:08:19 +0400
Yuri Tikhonov <yur@emcraft.com> 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 <concord@emcraft.com>
>  Acked-by: Yuri Tikhonov <yur@emcraft.com>
> 
> --
> 
> 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

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

josh

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Wolfgang Denk]

Dear Josh,

in message <20071019113634.397c63f7@weaponx.rchland.ibm.com> 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 0x40000 (as opposite to standard 0x10000).
...
> 
> 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

-- 
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: wd@denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Yuri Tikhonov]

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 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?

 
 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.

-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Segher Boessenkool]

>>>> 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?
>
>  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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Segher Boessenkool]

> 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

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Paul Mackerras]

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.

Re: [PATCH] ppc44x: support for 256K PAGE_SIZE

[Paul Mackerras]

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