Re: Low memory problems in 8xx Linux

7 messages, 3 authors, 2000-02-09 · open the first message on its own page

Re: Low memory problems in 8xx Linux

From: Jesper Skov <hidden>
Date: 2000-02-08 10:01:55

quoted
quoted
quoted
quoted
"Peter" == Peter Allworth [off-list ref] writes:
Peter> duncanp@research.canon.com.au wrote:
quoted
 Dan,

On 1 Feb, Dan Malek wrote: > I have already incorporated most of
these into 2.3.xx > kernel, and a 2.2.13 version that I will update
as a tar file > on a server.

would you mind posting a diff against the current 2.2.13 kernel on
the ftp server when you do this as well? we've got a kernel in CVS
here (i imagine plently of others are doing this too), and it would
be easier for us if we can patch it.

Dunk.
Peter> Dunk,

Peter> If you need the MMU patches straight-away, I've put them on

Peter> http://www.zeta.org.au/~linsol

Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
Peter> sent me a revised patch which should work for other 2.2 kernels
Peter> (caveat emptor).  I'll try to add that asap.

Peter and Duncan,

The 2.2.13 patch you posted was slightly (but critically) wrong, if
I'm not mistaken. The value updated in memory was not reloaded into
r21 which is where the code below this snipped expects to find the
value.

This patch should do the trick. At least my kernel seems to work.

--- head.S.orig	Sat Oct 23 00:18:03 1999
+++ head.S	Tue Feb  8 10:34:02 2000
@@ -1024,6 +1024,18 @@
 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	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 */
+	andi.	r20, r20, _PAGE_PRESENT		/* Set cr0 if it's invalid */
+	beq	4f				/* Skip update if invalid */
+	mfspr	r20, DSISR			/* Check for store op */
+	andis.	r20, r20, 0x0200		/* If set, indicates store */
+	lwz	r20, 0(r21)			/* Get the pte again */
+	beq	3f
+	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
+3:
+	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
+	stw	r20, 0(r21)			/* Update the pte */
+4:
 	lwz	r21, 0(r21)	/* Get the pte */

 	/* Set four subpage valid bits (24, 25, 26, and 27).

An alternative and slighly faster implementation might be to skip the
_PAGE_PRESENT check. Any reason something like this wouldn't work?


 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	mtspr	MD_TWC, r21	/* Load pte table base address */
 	mfspr	r21, MD_TWC	/* ....and get the pte address */
	mfspr	r20, DSISR			/* Check for store op */
	andis.	r20, r20, 0x0200		/* If set, indicates store */
	lwz	r20, 0(r21)			/* Get the pte again */
	beq	3f
	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
3:
	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
	stw	r20, 0(r21)			/* Update the pte */
 	mr	r21, r20	/* Get the pte */


Cheers,
Jesper

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Low memory problems in 8xx Linux

From: Peter Allworth <hidden>
Date: 2000-02-09 00:00:13

Jesper Skov wrote:
quoted
quoted
quoted
quoted
quoted
"Peter" == Peter Allworth [off-list ref] writes:
<snip>
Peter> If you need the MMU patches straight-away, I've put them on

Peter> http://www.zeta.org.au/~linsol

Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
Peter> sent me a revised patch which should work for other 2.2 kernels
Peter> (caveat emptor).  I'll try to add that asap.

Peter and Duncan,

The 2.2.13 patch you posted was slightly (but critically) wrong, if
I'm not mistaken. The value updated in memory was not reloaded into
r21 which is where the code below this snipped expects to find the
value.

This patch should do the trick. At least my kernel seems to work.
Jesper,

Which kernel are you using and which patch file?
(Please double-check the readme.txt file.)

My http://www.zeta.org.au/~linsol directory contains two versions of the
patch to head.S. If you are using cllf-2.2.13 which includes the use of
r21 as you've described, then use "head.S-patch".

Marcus Sundberg provided the other file "head.S.non-cllf" which is
for older kernels that used r20 for the pte and didn't do the update
of the GUARDED bit. (I need to change the names in the diff headers
to make this clearer.)

You are wise to be cautious, however.
Neither Marcus (as far as I know) nor I have tested "head.S-non-cllf".
(Also, having just taken a second look at the file, I notice it doesn't
include all of the changes so I'd regard it as informational only.)

As for optimising away the _PAGE_PRESENT test, I haven't thought through
whether that can be done or not. It's a couple of weeks since I made the
change and the whole think is definitely a quick-and-dirty fix
(no pun intended). What I was trying to avoid was making a reference
to a second level page table through an invalid entry in the first level
table. You've prompted me to take another look at this code!

Cheers,

PeterA.
quoted hunk
--- head.S.orig Sat Oct 23 00:18:03 1999
+++ head.S      Tue Feb  8 10:34:02 2000
@@ -1024,6 +1024,18 @@
        ori     r21, r21, 1     /* Set valid bit in physical L2 page */
        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 */
+       andi.   r20, r20, _PAGE_PRESENT         /* Set cr0 if it's invalid */
+       beq     4f                              /* Skip update if invalid */
+       mfspr   r20, DSISR                      /* Check for store op */
+       andis.  r20, r20, 0x0200                /* If set, indicates store */
+       lwz     r20, 0(r21)                     /* Get the pte again */
+       beq     3f
+       ori     r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
+3:
+       ori     r20, r20, _PAGE_ACCESSED        /* Set the accessed flag */
+       stw     r20, 0(r21)                     /* Update the pte */
+4:
        lwz     r21, 0(r21)     /* Get the pte */

        /* Set four subpage valid bits (24, 25, 26, and 27).
An alternative and slighly faster implementation might be to skip the
_PAGE_PRESENT check. Any reason something like this wouldn't work?

        ori     r21, r21, 1     /* Set valid bit in physical L2 page */
        mtspr   MD_TWC, r21     /* Load pte table base address */
        mfspr   r21, MD_TWC     /* ....and get the pte address */
        mfspr   r20, DSISR                      /* Check for store op */
        andis.  r20, r20, 0x0200                /* If set, indicates store */
        lwz     r20, 0(r21)                     /* Get the pte again */
        beq     3f
        ori     r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
3:
        ori     r20, r20, _PAGE_ACCESSED        /* Set the accessed flag */
        stw     r20, 0(r21)                     /* Update the pte */
        mr      r21, r20        /* Get the pte */

Cheers,
Jesper
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

more Re: Low memory problems in 8xx Linux

From: Peter Allworth <hidden>
Date: 2000-02-09 01:11:50

Jesper Skov wrote:

<snip>
An alternative and slighly faster implementation might be to skip the
_PAGE_PRESENT check. Any reason something like this wouldn't work?
<snip>

I had another look at the code and I now remember my rationale for
the _PAGE_PRESENT test. It wasn't to do with level 1 table entries,
Dan's code already takes care of that. It was so that a zeroed pte
couldn't get changed to a non-zero value, since that would make the
pte_none() function return the wrong result. (Moreover, it just seemed
wrong to mess with something that's marked "invalid".)

Admittedly I'm being a bit paranoid since the next thing the exception
handler is likely to do is set the page table entry to something valid.
But, can you be sure? What about a segmentation fault? ;)

Cheers,

PeterA.

"I've always considered a paranoid as a man with all the facts."
	-- Tales of Ordinary Madness

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: more Re: Low memory problems in 8xx Linux

From: Dan Malek <hidden>
Date: 2000-02-09 05:52:13

Just a note to let you guys know you are getting just a little
carried away here.....

You are placing things in the TLB specific handler that are
supposed to be handled generically in places like arch/ppc/mm/fault.c.

Yes, it may be a little bit of a speed improvement, but you
are placing code in the TLB miss handler that logically should
be executed as part of the TLB Error handler.  In some cases,
it is appropriate to store something in the TLB that will cause
a subsequent fault into the TLB Error handler (i.e. a pte that
doesn't look valid).  If you continue down this path, you will
end up exceeding the space allocated for the trap handler, and
simply re-implement code found elsewhere.

While some of the updates are genuine bugs that should be corrected,
some of the other stuff isn't proper, so don't be surprised when
it doesn't show up in the real kernel sources.



	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: more Re: Low memory problems in 8xx Linux

From: Jesper Skov <hidden>
Date: 2000-02-09 08:40:03

quoted
quoted
quoted
quoted
"Peter" == Peter Allworth [off-list ref] writes:
Peter> Jesper Skov wrote: <snip>
quoted
An alternative and slighly faster implementation might be to skip
the _PAGE_PRESENT check. Any reason something like this wouldn't
work?
Peter> <snip>

Peter> I had another look at the code and I now remember my rationale
Peter> for the _PAGE_PRESENT test. It wasn't to do with level 1 table
Peter> entries, Dan's code already takes care of that. It was so that
Peter> a zeroed pte couldn't get changed to a non-zero value, since
Peter> that would make the pte_none() function return the wrong
Peter> result. (Moreover, it just seemed wrong to mess with something
Peter> that's marked "invalid".)

Peter> Admittedly I'm being a bit paranoid since the next thing the
Peter> exception handler is likely to do is set the page table entry
Peter> to something valid.  But, can you be sure? What about a
Peter> segmentation fault? ;)

No, sounds sensible.

Jesper

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Low memory problems in 8xx Linux

From: Jesper Skov <hidden>
Date: 2000-02-09 08:43:49

quoted
quoted
quoted
quoted
"Peter" == Peter Allworth [off-list ref] writes:
Peter> Jesper Skov wrote:
quoted
 >>>>> "Peter" == Peter Allworth [off-list ref] writes:
Peter> <snip>

Peter> If you need the MMU patches straight-away, I've put them on
quoted
Peter> http://www.zeta.org.au/~linsol
quoted
Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
Peter> sent me a revised patch which should work for other 2.2 kernels
Peter> (caveat emptor).  I'll try to add that asap.
quoted
 Peter and Duncan,

The 2.2.13 patch you posted was slightly (but critically) wrong, if
I'm not mistaken. The value updated in memory was not reloaded into
r21 which is where the code below this snipped expects to find the
value.

This patch should do the trick. At least my kernel seems to work.
Peter> Jesper,

Peter> Which kernel are you using and which patch file?  (Please
Peter> double-check the readme.txt file.)

I was assuming one of the patches was for
ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/mpc8xx-2.2.13.tgz, but
I don't think either matches very well.

Peter> My http://www.zeta.org.au/~linsol directory contains two
Peter> versions of the patch to head.S. If you are using cllf-2.2.13
Peter> which includes the use of r21 as you've described, then use
Peter> "head.S-patch".

Peter> Marcus Sundberg provided the other file "head.S.non-cllf" which
Peter> is for older kernels that used r20 for the pte and didn't do
Peter> the update of the GUARDED bit. (I need to change the names in
Peter> the diff headers to make this clearer.)

I read the patch and think I understand what's going on, but I don't
see where the GUARDED bits comes in. Maybe I'm missing some subtlety
from other patches (cllf?) and should not use the code at all. I'd
better back it out.

Jesper

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Low memory problems in 8xx Linux

From: Peter Allworth <hidden>
Date: 2000-02-09 23:26:30

Jesper Skov wrote:

<snip>
I read the patch and think I understand what's going on, but I don't
see where the GUARDED bits comes in. Maybe I'm missing some subtlety
from other patches (cllf?) and should not use the code at all. I'd
better back it out.

Jesper
Apologies for being vague. I have a head-cold and my brain seems to be
on vacation. :(

The guarded flag doesn't appear in the patch but in

cllf-2.2.13/arch/ppc/kernel/head.S
(from Dan's distribution for the Classic Lite Low Fat board)

near where the head.S-patch is applied.

Somewhere in the DataStoreTLBMiss routine, I think, you'll see the comment:

/* Insert the Guarded flag into the TWC from the Linux PTE.
<snip>
*/

This is one of the areas where cllf-2.2.13 differs from mpc8xx-2.2.13.

HTH,

PeterA.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help