[PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Joakim Tjernlund]

This adds Large page support for 8xx and uses it
for all kernel RAM.

Further usage is possible, IMAP_ADDR and on board
flash comes to mind.

There is one bit free the pte which could be used for
selecting different large page sizes but that is for another
day.

- Dan, what do you think :)

Joakim Tjernlund (3):
  8xx: replace _PAGE_EXEC with _PAGE_PSE
  8xx: Support LARGE pages in TLB code.
  8xx: Use LARGE pages for kernel RAM.

 arch/ppc/kernel/head_8xx.S |   30 +++++++++++++++++++-----------
 arch/ppc/mm/pgtable.c      |    4 +++-
 include/asm-ppc/pgtable.h  |    6 +++++-
 3 files changed, 27 insertions(+), 13 deletions(-)

-- 
1.7.3.4

[PATCH 1/3] 8xx: replace _PAGE_EXEC with _PAGE_PSE

[Joakim Tjernlund]

We need this bit for large pages(8MB). Adjust TLB code
to not clear bit 28 Mx_RPN

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/ppc/kernel/head_8xx.S |    8 ++++----
 include/asm-ppc/pgtable.h  |    6 +++++-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 36089cc..8e3fe40 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -387,13 +387,13 @@ InstructionTLBMiss:
 4:
 #endif
 	/* The Linux PTE won't go exactly into the MMU TLB.
-	 * Software indicator bits 21 and 28 must be clear.
+	 * Software indicator bit 21 must be clear.
 	 * Software indicator bits 24, 25, 26, and 27 must be
 	 * set.  All other Linux PTE bits control the behavior
 	 * of the MMU.
 	 */
 2:	li	r21, 0x00f0
-	rlwimi	r20, r21, 0, 0x07f8	/* Set 24-27, clear 21-23,28 */
+	rlwimi	r20, r21, 0, 0x07f0	/* Set 24-27, clear 21-23 */
 	DO_8xx_CPU6(0x2d80, r3)
 	mtspr	MI_RPN, r20	/* Update TLB entry */
 
@@ -475,7 +475,7 @@ DataStoreTLBMiss:
 	xori	r20, r20, _PAGE_RW | 0x200
 
 	/* The Linux PTE won't go exactly into the MMU TLB.
-	 * Software indicator bits 22 and 28 must be clear.
+	 * Software indicator bit 22 must be clear.
 	 * Software indicator bits 24, 25, 26, and 27 must be
 	 * set.  All other Linux PTE bits control the behavior
 	 * of the MMU.
@@ -483,7 +483,7 @@ DataStoreTLBMiss:
 finish_DTLB:
 2:	li	r21, 0x00f0
 	mtspr	DAR, r21	/* Tag DAR */
-	rlwimi	r20, r21, 0, 24, 28	/* Set 24-27, clear 28 */
+	rlwimi	r20, r21, 0, 0x00f0	/* Set 24-27 */
 	DO_8xx_CPU6(0x3d80, r3)
 	mtspr	MD_RPN, r20	/* Update TLB entry */
 
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index b94e8a8..1a0ca7b 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -297,11 +297,11 @@ extern unsigned long vmalloc_start;
 #define _PAGE_PRESENT	0x0001	/* Page is valid */
 #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
 #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
+#define _PAGE_PSE	0x0008	/* Large Page, 8MB */
 
 /* These four software bits must be masked out when the entry is loaded
  * into the TLB, 1 SW bits left(0x0080).
  */
-#define _PAGE_EXEC	0x0008	/* software: i-cache coherency required */
 #define _PAGE_GUARDED	0x0010	/* software: guarded access */
 #define _PAGE_ACCESSED	0x0020	/* software: page referenced */
 #define _PAGE_WRITETHRU	0x0040	/* software: caching is write through */
@@ -359,6 +359,10 @@ extern unsigned long vmalloc_start;
 #define _PAGE_EXEC	0
 #endif
 
+#ifndef _PAGE_PSE
+#define _PAGE_PSE	0
+#endif
+
 #define _PAGE_CHG_MASK	(PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY)
 
 /*
-- 
1.7.3.4

[PATCH 2/3] 8xx: Support LARGE pages in TLB code.

[Joakim Tjernlund]

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/ppc/kernel/head_8xx.S |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 8e3fe40..439e7f2 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -368,15 +368,19 @@ InstructionTLBMiss:
 	 * for this "segment."
 	 */
 	tophys(r21,r21)
-	ori	r21,r21,1		/* Set valid bit */
-	DO_8xx_CPU6(0x2b80, r3)
-	mtspr	MI_TWC, r21	/* Set segment attributes */
 	beq-	2f		/* If zero, don't try to find a pte */
 	DO_8xx_CPU6(0x3b80, r3)
 	mtspr	MD_TWC, r21	/* Load pte table base address */
-	mfspr	r21, MD_TWC	/* ....and get the pte address */
-	lwz	r20, 0(r21)	/* Get the pte */
+	mfspr	r20, MD_TWC	/* ....and get the pte address */
+	lwz	r20, 0(r20)	/* Get the pte */
+
+	ori	r21, r21, MI_SVALID	/* Set valid bit */
+	/* Copy PSE to PS bits(8MB) */
+	rlwimi	r21, r20, 0, _PAGE_PSE
+	rlwimi	r21, r20, 32-1, _PAGE_PSE>>1
 
+	DO_8xx_CPU6(0x2b80, r3)
+	mtspr	MI_TWC, r21	/* Set segment attributes */
 #ifndef NO_SWAP
 	/* if !swap, you can delete this */
 	andi.	r21, r20, _PAGE_ACCESSED	/* test ACCESSED bit */
@@ -446,7 +450,9 @@ DataStoreTLBMiss:
 	 * this into the Linux pgd/pmd and load it in the operation
 	 * above.
 	 */
-	rlwimi	r21, r20, 0, _PAGE_GUARDED
+	rlwimi	r21, r20, 0, _PAGE_GUARDED | _PAGE_PSE
+	/* Copy PSE to PS bits(8MB), combine with GUARDED above */
+	rlwimi	r21, r20, 32-1, _PAGE_PSE>>1
 	/* Insert the WriteThru flag into the TWC from the Linux PTE.
 	 * It is bit 25 in the Linux PTE and bit 30 in the TWC
 	 */
@@ -589,7 +595,9 @@ DARFixed:
 	/* Insert the Guarded flag into the TWC from the Linux PTE.
 	 * It is bit 27 of both the Linux PTE and the TWC
 	 */
-	rlwimi	r21, r20, 0, _PAGE_GUARDED
+	rlwimi	r21, r20, 0, _PAGE_GUARDED | _PAGE_PSE
+	/* Copy PSE to PS bits(8MB), combine with GUARDED above */
+	rlwimi	r21, r20, 32-1, _PAGE_PSE>>1
 	/* Insert the WriteThru flag into the TWC from the Linux PTE.
 	 * It is bit 25 in the Linux PTE and bit 30 in the TWC
 	 */
-- 
1.7.3.4

[PATCH 3/3] 8xx: Use LARGE pages for kernel RAM.

[Joakim Tjernlund]

Use the new _PAGE_PSE to map all kernel RAM with 8 MB TLBs

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/ppc/mm/pgtable.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
index 866ae43..56e847e 100644
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -298,7 +298,9 @@ void __init mapin_ram(void)
 		/* On the MPC8xx, we want the page shared so we
 		 * don't get ASID compares on kernel space.
 		 */
-		f = _PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_SHARED | _PAGE_HWEXEC;
+		f = _PAGE_PSE | _PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_SHARED | _PAGE_HWEXEC;
+		if (_PAGE_PSE)
+			f |= _PAGE_WRENABLE;
 #if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH)
 		/* Allows stub to set breakpoints everywhere */
 		f |= _PAGE_WRENABLE;
-- 
1.7.3.4

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Dan Malek]

Hi Joakim.

On Oct 10, 2011, at 4:38 AM, Joakim Tjernlund wrote:

> This adds Large page support for 8xx and uses it
> for all kernel RAM....

> - Dan, what do you think :)

Since you asked, yes it looks great :-)  Now, can we
get this into a more contemporary kernel?  I'm
actually working on an 8xx project that may have
a few years of life left.

Thanks.

	-- Dan

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Willy Tarreau]

Hi an,

On Mon, Oct 10, 2011 at 09:22:09AM -0700, Dan Malek wrote:
> 
> Hi Joakim.
> 
> On Oct 10, 2011, at 4:38 AM, Joakim Tjernlund wrote:
> 
> >This adds Large page support for 8xx and uses it
> >for all kernel RAM....
> 
> >- Dan, what do you think :)
> 
> Since you asked, yes it looks great :-)  Now, can we
> get this into a more contemporary kernel?  I'm
> actually working on an 8xx project that may have
> a few years of life left.

At the pace of current 2.4, I'm sure the code won't have change
much a few years from now :-) It would be nice to know by now if
the current longterm branches work OK or not though.

Cheers,
Willy

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Joakim Tjernlund]

Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/10/10 18:22:09:
>
>
> Hi Joakim.
>
> On Oct 10, 2011, at 4:38 AM, Joakim Tjernlund wrote:
>
> > This adds Large page support for 8xx and uses it
> > for all kernel RAM....
>
> > - Dan, what do you think :)
>
> Since you asked, yes it looks great :-)  Now, can we
> get this into a more contemporary kernel?  I'm
> actually working on an 8xx project that may have
> a few years of life left.

That is an easy port but I will have to do that blind. Would you
mind take this for a spin on 2.4 first?

The more interesting part is if one should use other sized(16K or 512K) large pages too?
Those should be useful for user space but it is a lot of work. I haven't checked
what large page support for user space is in 2.6 for ppc though.

 Jocke

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Dan Malek]

On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote:

> That is an easy port but I will have to do that blind. Would you
> mind take this for a spin on 2.4 first?

My current system is running 2.6, so I don't have much
interested in testing 2.4

> The more interesting part is if one should use other sized(16K or  
> 512K) large pages too?

My thought long ago was most of the 8xx systems have rather small
real memories, so the larger pages, especially 512K may be too wasteful.
I've always been a fan of keeping the TLB handlers tiny and simple,
rather then spending the instructions doing complex replacements.
Remember, this also affects the I- and D-cache, so a more frequent
and trivial PTE update could very well gain larger system performance
than the management of larger pages with more complex code.
With all of the bug fix code in the handlers, maybe a larger page would
be better.

> Those should be useful for user space but it is a lot of work. I  
> haven't checked
> what large page support for user space is in 2.6 for ppc though.

The 2.6/3.0 kernel supports different, but fixed, page sizes.  IIRC,  
anything
over 64K may require distribution rebuilding to realign code/data  
sections
to more restrictive boundaries.  Maybe a 16K page would show some  
benefit.
I'll try to make some time to play with it.

Thanks.

	-- Dan

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Joakim Tjernlund]

Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/10/10 20:03:53:
>
>
> On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote:
>
> > That is an easy port but I will have to do that blind. Would you
> > mind take this for a spin on 2.4 first?
>
> My current system is running 2.6, so I don't have much
> interested in testing 2.4

Too bad as I won't be able to run 2.6 at all.
However, I just sent you a dry port to 3.0 of the large page stuff to
you. Happy testing.

>
> > The more interesting part is if one should use other sized(16K or
> > 512K) large pages too?
>
> My thought long ago was most of the 8xx systems have rather small
> real memories, so the larger pages, especially 512K may be too wasteful.
> I've always been a fan of keeping the TLB handlers tiny and simple,
> rather then spending the instructions doing complex replacements.
> Remember, this also affects the I- and D-cache, so a more frequent
> and trivial PTE update could very well gain larger system performance
> than the management of larger pages with more complex code.
> With all of the bug fix code in the handlers, maybe a larger page would
> be better.
>
> > Those should be useful for user space but it is a lot of work. I
> > haven't checked
> > what large page support for user space is in 2.6 for ppc though.
>
> The 2.6/3.0 kernel supports different, but fixed, page sizes.  IIRC,
> anything
> over 64K may require distribution rebuilding to realign code/data
> sections
> to more restrictive boundaries.  Maybe a 16K page would show some
> benefit.
> I'll try to make some time to play with it.

Unfortunately 3.0 does not have any free PTE bits now. I had to move
_PAGE_SPECIAL to the last available one as the new _PAGE_PSE needed its place.
Don't know what _PAGE_SPECIAL is but if it cannot be removed one can always skip
_PAGE_WRITETHRU again.

 Jocke

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2011/10/11 09:42:58:
>
> Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/10/10 20:03:53:
> >
> >
> > On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote:
> >
> > > That is an easy port but I will have to do that blind. Would you
> > > mind take this for a spin on 2.4 first?
> >
> > My current system is running 2.6, so I don't have much
> > interested in testing 2.4
>
> Too bad as I won't be able to run 2.6 at all.
> However, I just sent you a dry port to 3.0 of the large page stuff to
> you. Happy testing.

Dan, where did you go? I figured you would throw yourself at this as this is
something you been meaning to do yourself for years :)

 Jocke

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Dan Malek]

Hi Joakim.

On Oct 12, 2011, at 2:36 PM, Joakim Tjernlund wrote:

> Dan, where did you go? I figured you would throw yourself at this as  
> this is
> something you been meaning to do yourself for years :)

Too many things to do :-)  I did have the wired page version that I've
been using now and then.

I had the bad thought yesterday that we need to check the
implementation for coherent memory.  It appears we set the
pages non-cached, which could cause some trouble.  We
have to ensure we never access the same physical page
with different attributes from the 8M mapping and the single
page "coherent" mapping.

I'll try to get some testing done.

Thanks.

	-- Dan

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Joakim Tjernlund]

Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/10/13 03:08:12:
>
>
> Hi Joakim.
>
> On Oct 12, 2011, at 2:36 PM, Joakim Tjernlund wrote:
>
> > Dan, where did you go? I figured you would throw yourself at this as
> > this is
> > something you been meaning to do yourself for years :)
>
> Too many things to do :-)  I did have the wired page version that I've
> been using now and then.

ehhm, do the fun stuff first? :)

>
> I had the bad thought yesterday that we need to check the
> implementation for coherent memory.  It appears we set the
> pages non-cached, which could cause some trouble.  We
> have to ensure we never access the same physical page
> with different attributes from the 8M mapping and the single
> page "coherent" mapping.
>
> I'll try to get some testing done.

In 2.4 this seems fine:
#ifdef CONFIG_PIN_TLB
#define VMALLOC_OFFSET (0x2000000) /* 32M */
#else
#define VMALLOC_OFFSET (0x1000000) /* 16M */
#endif
...
	/* adjust vmalloc_start */
	vmalloc_start = (vmalloc_start + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1);

Earlier you have
MMU_init(void)
{
....
	vmalloc_start = KERNELBASE + total_lowmem;

You could add 8MB to that just to be sure. In my system there is no consistent_alloc so
early though.

 Jocke

BTW, I noted that you can remove the
	ori	r11, r11, 1	/* Set valid bit in physical L2 page */
insns in the TLB routines in 3.0, the valid bit is now set be the mm system.

 Jocke

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

[Dan Malek]

On Oct 13, 2011, at 7:00 AM, Joakim Tjernlund wrote:

> ehhm, do the fun stuff first? :)

Need to pay the bills, first :-)
Thanks for the other information.

	-- Dan