mpc880 linux-2.6.32 slow running processes

Hello all,
I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.
The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).
Monitoring the network packets, I can see that the nfs protocol is exchanged
just fine, but at some time it simply stops, starting again with a request
from the board several seconds later.
I'm thinking that the processor is running (something, I don't know what)
for all this time before I can see requests coming from the board again. I
pinged the board from the PC and during all this I can see the packets being
answered.

My question to all is, did anyone see something like this already? Besides
that, what is the status of the linux kernel support for the 8xx platform?
Is it being actively tested / used today? I ask this because it seems that
all the information on the internet very aged (forum discussions from 2005
and below mostly).

Is there something that I can do to try to narrow the cause of the problem?

Anyway, any help would be truly appreciated. Please excuse me if this is not
the right place to ask this too.

Thanks and best regards,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb

Dear Rafael Beims,

In message [off-list ref] you wrote:

I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.

2.6.32 is pretty old.  Is there any specific reason for not using a
recent kernel version?

The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).

This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.

My question to all is, did anyone see something like this already? Besides

We have seen this many times in the past, when interrupts were not
working correctly.  I recommend to check youyr device tree settings
for these.

[It would have helped if you had included a log of your kernel's boot
messages.]

that, what is the status of the linux kernel support for the 8xx platform?

It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).

Is it being actively tested / used today? I ask this because it seems that

Yes, it is.

all the information on the internet very aged (forum discussions from 2005
and below mostly).

Is there something that I can do to try to narrow the cause of the problem?

Check your interrupts.

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
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

Hello Mr. Denk

As I already posted, the patch that was posted before seems to have
solved the problem. Anyway, some answers follow:

On Wed, Jan 5, 2011 at 4:35 PM, Wolfgang Denk [off-list ref] wrote:

Dear Rafael Beims,

In message [off-list ref]=

 you wrote:

quoted

I'm working with an MPC880 board that is supposed to run linux-2.6.32. =

After

quoted

some work, I could get the kernel up and running, mounting a rootfs via
NFS.

2.6.32 is pretty old. =A0Is there any specific reason for not using a
recent kernel version?

The company that I work for uses some kernel versions in favor of
others... Maybe with time we can change that, but for now I need to
use this version.

quoted

The problem that I'm facing now is that when I try to run any process (=

may

quoted

be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).

This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.

quoted

My question to all is, did anyone see something like this already? Besi=

des

We have seen this many times in the past, when interrupts were not
working correctly. =A0I recommend to check youyr device tree settings
for these.

[It would have helped if you had included a log of your kernel's boot
messages.]

quoted

that, what is the status of the linux kernel support for the 8xx platfo=

rm?

It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).

quoted

Is it being actively tested / used today? I ask this because it seems t=

hat

Yes, it is.

This is very nice, because this way we can be more confident that
everything will work as it should.

quoted

all the information on the internet very aged (forum discussions from 2=

005

quoted

and below mostly).

quoted

Is there something that I can do to try to narrow the cause of the prob=

lem?

Check your interrupts.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, =A0 =A0 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
Never underestimate the power of human stupidity =A0when =A0it =A0comes =

=A0to

using technology they don't understand.

Thank you very much for the answers!

Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I understand=
."
- Chinese Proverb

Hi

On 01/05/2011 07:35 PM, Wolfgang Denk wrote:

Dear Rafael Beims,

In message[off-list ref]  you wrote:

quoted

I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.

2.6.32 is pretty old.  Is there any specific reason for not using a
recent kernel version?

I think that all the kernel version has the same problem

quoted

The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).

This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.

It is not a serial/console/interrupt problem

quoted

My question to all is, did anyone see something like this already? Besides

We have seen this many times in the past, when interrupts were not
working correctly.  I recommend to check youyr device tree settings
for these.

[It would have helped if you had included a log of your kernel's boot
messages.]

quoted

that, what is the status of the linux kernel support for the 8xx platform?

It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).

agree, this architecture is basically dead

quoted

Is it being actively tested / used today? I ask this because it seems that

Yes, it is.

quoted

all the information on the internet very aged (forum discussions from 2005
and below mostly).
Is there something that I can do to try to narrow the cause of the problem?

Check your interrupts.

Best regards,

Wolfgang Denk

Michael Trimarchi

Hi

On 01/05/2011 07:09 PM, Rafael Beims wrote:

Hello all,
I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.
The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).
Monitoring the network packets, I can see that the nfs protocol is exchanged
just fine, but at some time it simply stops, starting again with a request
from the board several seconds later.
I'm thinking that the processor is running (something, I don't know what)
for all this time before I can see requests coming from the board again. I
pinged the board from the PC and during all this I can see the packets being
answered.

Can you try this patch?

My question to all is, did anyone see something like this already? Besides
that, what is the status of the linux kernel support for the 8xx platform?
Is it being actively tested / used today? I ask this because it seems that
all the information on the internet very aged (forum discussions from 2005
and below mostly).

Is there something that I can do to try to narrow the cause of the problem?

Anyway, any help would be truly appreciated. Please excuse me if this is not
the right place to ask this too.

Thanks and best regards,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb



_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

On Wed, 5 Jan 2011 19:23:33 +0100
michael [off-list ref] wrote:

What do you think is going wrong with the special bit on 8xx?

Or might the change to set_pte_filter() alone be what fixed the problem?

Rex, do you recall under what specific circumstances the _tlbil_va is
needed?  Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG_arch_1?

-Scott

Hi

On 01/06/2011 12:42 AM, Scott Wood wrote:

On Wed, 5 Jan 2011 19:23:33 +0100
michael[off-list ref]  wrote:

quoted

diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index dd5ea95..cb67076 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h

@@ -32,7 +32,7 @@
  #define _PAGE_FILE	0x0002	/* when !present: nonlinear file mapping */
  #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
  #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
-#define _PAGE_SPECIAL	0x0008	/* SW entry, forced to 0 by the TLB miss */
+#define _PAGE_SPECIAL	0x0000	/* SW entry, forced to 0 by the TLB miss */

What do you think is going wrong with the special bit on 8xx?

Or might the change to set_pte_filter() alone be what fixed the problem?

Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.

quoted

diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..1da03a8 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c

@@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
  	pte = __pte(pte_val(pte)&  ~_PAGE_HPTEFLAGS);
  	if (pte_looks_normal(pte)&&  !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
  				       cpu_has_feature(CPU_FTR_NOEXECUTE))) {
-		struct page *pg = maybe_pte_to_page(pte);
-		if (!pg)
+		unsigned long pfn = pte_pfn(pte);
+		struct page *pg;
+
+		if (unlikely(!pfn_valid(pfn)))
  			return pte;
-		if (!test_bit(PG_arch_1,&pg->flags)) {
+
+		pg = pfn_to_page(pfn);
  #ifdef CONFIG_8xx
-			/* On 8xx, cache control instructions (particularly
-			 * "dcbst" from flush_dcache_icache) fault as write
-			 * operation if there is an unpopulated TLB entry
-			 * for the address in question. To workaround that,
-			 * we invalidate the TLB here, thus avoiding dcbst
-			 * misbehaviour.
-			 */
-			/* 8xx doesn't care about PID, size or ind args */
-			_tlbil_va(addr, 0, 0, 0);
+		/* On 8xx, cache control instructions (particularly
+		 * "dcbst" from flush_dcache_icache) fault as write
+		 * operation if there is an unpopulated TLB entry
+		 * for the address in question. To workaround that,
+		 * we invalidate the TLB here, thus avoiding dcbst
+		 * misbehaviour.
+		 */
+		/* 8xx doesn't care about PID, size or ind args */
+		_tlbil_va(addr, 0, 0, 0);
  #endif /* CONFIG_8xx */
+
+		if (!pg)
+			return pte;
+
+		if (!PageReserved(pg)&&  !test_bit(PG_arch_1,&pg->flags)) {
  			flush_dcache_icache_page(pg);
  			set_bit(PG_arch_1,&pg->flags);
  		}

Rex, do you recall under what specific circumstances the _tlbil_va is
needed?  Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG_arch_1?

-Scott

Michael

quoted

quoted

+  /* On 8xx, cache control instructions (particularly
+   * "dcbst" from flush=5Fdcache=5Ficache) fault as write
+   * operation if there is an unpopulated TLB entry
+   * for the address in question. To workaround that,
+   * we invalidate the TLB here, thus avoiding dcbst
+   * misbehaviour.
+   */
+  /* 8xx doesn't care about PID, size or ind args */
+  =5Ftlbil=5Fva(addr, 0, 0, 0);
  #endif /* CONFIG=5F8xx */
+
+  if (!pg)
+   return pte;
+
+  if (!PageReserved(pg)&&  !test=5Fbit(PG=5Farch=5F1,&pg->flags)) {
     flush=5Fdcache=5Ficache=5Fpage(pg);
     set=5Fbit(PG=5Farch=5F1,&pg->flags);
    }

Rex, do you recall under what specific circumstances the =5Ftlbil=5Fva is
needed?  Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG=5Farch=5F1?

The 8xx tlbil=5Fva should not be needed in recent 2.6 after I fixed the 8xx=
 TLB code
to workaround the dcbst bug there instead. See=20
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98c3=
7d03a4a7c5a3f8b1e3b8e5

Not sure what release it went into though.

 Jocke=
=

On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
[off-list ref] wrote:

The 8xx tlbil_va should not be needed in recent 2.6 after I fixed the 8xx=

 TLB code

to workaround the dcbst bug there instead. See
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=

mmitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98=
c37d03a4a7c5a3f8b1e3b8e5

Not sure what release it went into though.

=A0Jocke

I saw that the commit you mention did make it in the 2.6.33 version. I
will try to boot it here and see if the problem is also solved in this
version.

Rafael

Rafael Beims [off-list ref] wrote on 2011/01/07 11:00:56:

On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
[off-list ref] wrote:

quoted

The 8xx tlbil_va should not be needed in recent 2.6 after I fixed t=

he 8xx TLB code

quoted

to workaround the dcbst bug there instead. See
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;=

a=3Dcommitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071=
fee994ff98c37d03a4a7c5a3f8b1e3b8e5

quoted

Not sure what release it went into though.

=A0Jocke

I saw that the commit you mention did make it in the 2.6.33 version. =

I

will try to boot it here and see if the problem is also solved in thi=

s

version.

Once you have tested it and it works, please send a patch to remove the=
 8xx workaround.
Make sure Scott is cc:ed=

Once you have tested it and it works, please send a patch to remove the 8xx workaround.
Make sure Scott is cc:ed

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Thanks for all the help so far,
Rafael

Rafael Beims [off-list ref] wrote on 2011/01/10 17:35:38:

quoted

Once you have tested it and it works, please send a patch to remove the 8xx workaround.
Make sure Scott is cc:ed

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
			/* On 8xx, cache control instructions (particularly
			 * "dcbst" from flush_dcache_icache) fault as write
			 * operation if there is an unpopulated TLB entry
			 * for the address in question. To workaround that,
			 * we invalidate the TLB here, thus avoiding dcbst
			 * misbehaviour.
			 */
			/* 8xx doesn't care about PID, size or ind args */
			_tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */

Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.

    Jocke

Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org

Rafael Beims [off-list ref] wrote on 2011/01/10 17:35:38:

quoted

quoted

Once you have tested it and it works, please send a patch to remove the 8xx workaround.
Make sure Scott is cc:ed

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
         /* On 8xx, cache control instructions (particularly
          * "dcbst" from flush_dcache_icache) fault as write
          * operation if there is an unpopulated TLB entry
          * for the address in question. To workaround that,
          * we invalidate the TLB here, thus avoiding dcbst
          * misbehaviour.
          */
         /* 8xx doesn't care about PID, size or ind args */
         _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */

Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.

Can you test these 2 patches on recent 2.6 linux:

From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:43:42 +0100
Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs

8xx does not invalidate ~PRESENT TLBs, move the workaround
in mm/fault.c here to keep 8xx quirks localized and expedite
the invalidation faster.

Signed-off-by: Joakim Tjernlund <redacted>
---
 arch/powerpc/kernel/head_8xx.S |   12 ++++++++++--
 arch/powerpc/mm/fault.c        |    6 ------
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1f1a04b..6cd99e2 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S

@@ -221,7 +221,11 @@ DataAccess:
 	stw	r10,_DSISR(r11)
 	mr	r5,r10
 	mfspr	r4,SPRN_DAR
-	li	r10,0x00f0
+	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
+	andis.	r10,r5,0x4000
+	beq+	1f
+	tlbie	r4
+1:	li	r10,0x00f0
 	mtspr	SPRN_DAR,r10	/* Tag DAR, to be used in DTLB Error */
 	EXC_XFER_EE_LITE(0x300, handle_page_fault)

@@ -234,7 +238,11 @@ InstructionAccess:
 	EXCEPTION_PROLOG
 	mr	r4,r12
 	mr	r5,r9
-	EXC_XFER_EE_LITE(0x400, handle_page_fault)
+	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
+	andis.	r10,r5,0x4000
+	beq+	1f
+	tlbie	r4
+1:	EXC_XFER_EE_LITE(0x400, handle_page_fault)

 /* External interrupt */
 	EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE)

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 1bd712c..31226c8 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c

@@ -247,12 +247,6 @@ good_area:
 		goto bad_area;
 #endif /* CONFIG_6xx */
 #if defined(CONFIG_8xx)
-	/* 8xx sometimes need to load a invalid/non-present TLBs.
-	 * These must be invalidated separately as linux mm don't.
-	 */
-	if (error_code & 0x40000000) /* no translation? */
-		_tlbil_va(address, 0, 0, 0);
-
         /* The MPC8xx seems to always set 0x80000000, which is
          * "undefined".  Of those that can be set, this is the only
          * one which seems bad.
--

1.7.3.4


and

From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:55:22 +0100
Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.

On 8xx dcbst fault as write operation if there is an unpopulated TLB entry
for the address in question. There is as of commit
0a2ab51ffb8dfdf51402dcfb446629648c96bc78,
powerpc/8xx: Fixup DAR from buggy dcbX instructions
a better workaround in the TLB error handler so this bad
one can be removed.

Signed-off-by: Joakim Tjernlund <redacted>
---
 arch/powerpc/mm/pgtable.c |   11 -----------
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ebc2f38..d3f47a6 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c

@@ -185,17 +185,6 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
 		if (!pg)
 			return pte;
 		if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
-			/* On 8xx, cache control instructions (particularly
-			 * "dcbst" from flush_dcache_icache) fault as write
-			 * operation if there is an unpopulated TLB entry
-			 * for the address in question. To workaround that,
-			 * we invalidate the TLB here, thus avoiding dcbst
-			 * misbehaviour.
-			 */
-			/* 8xx doesn't care about PID, size or ind args */
-			_tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
 			flush_dcache_icache_page(pg);
 			set_bit(PG_arch_1, &pg->flags);
 		}
--

1.7.3.4

Hello Joakim,

Joakim Tjernlund wrote:

quoted

Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org

Rafael Beims [off-list ref] wrote on 2011/01/10 17:35:38:

quoted

quoted

Once you have tested it and it works, please send a patch to remove the 8xx workaround.
Make sure Scott is cc:ed

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
         /* On 8xx, cache control instructions (particularly
          * "dcbst" from flush_dcache_icache) fault as write
          * operation if there is an unpopulated TLB entry
          * for the address in question. To workaround that,
          * we invalidate the TLB here, thus avoiding dcbst
          * misbehaviour.
          */
         /* 8xx doesn't care about PID, size or ind args */
         _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */

Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.

Can you test these 2 patches on recent 2.6 linux:

quoted

From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:43:42 +0100
Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs

[...]

and

quoted

From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:55:22 +0100
Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.

Tested this on a board similliar to the mainline tqm8xx board with
lmbench:

-bash-3.2# cat /proc/cpuinfo
processor       : 0
cpu             : 8xx
clock           : 80.000000MHz
revision        : 0.0 (pvr 0050 0000)
bogomips        : 10.00
timebase        : 5000000
platform        : KUP4K
model           : KUP4K
Memory          : 96 MB
-bash-3.2#

-bash-3.2# cat /proc/version
Linux version 2.6.34-00064-g3e81b6b (hs@pollux.denx.de) (gcc version 4.2.2) #89 Thu Jan 20 08:39:52 CET 2011
-bash-3.2#

(First run of lmbench without your 2 patches, the two other runs with it)

-bash-3.2# make see
cd results && make summary >summary.out 2>summary.errs
cd results && make percent >percent.out 2>percent.errs
-bash-3.2# cat results/summary.out
make[1]: Entering directory `/home/hs/lmbench-3.0-a9/results'

                 L M B E N C H  3 . 0   S U M M A R Y
                 ------------------------------------
                 (Alpha software, do not distribute)

Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.1400    1
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.0200    1
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.1000    1

Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
kup4k     Linux 2.6.34-   79 2.58 12.3 126. 1285 353. 22.8 149. 8418 34.K 101K
kup4k     Linux 2.6.34-   79 2.59 13.1 127. 1273 320. 23.4 127. 8251 33.K 100K
kup4k     Linux 2.6.34-   79 2.47 13.1 127. 1288 315. 23.6 128. 8413 34.K 101K

Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr
                          bit   add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
kup4k     Linux 2.6.34-   12.6   14.4 1.3500  103.9  170.6
kup4k     Linux 2.6.34-   13.2   15.0 1.3100  100.0  170.5
kup4k     Linux 2.6.34-   13.2   14.4 1.2900  104.1  162.1

Basic uint64 operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS int64  int64  int64  int64  int64
                         bit    add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
kup4k     Linux 2.6.34-    12.          11.1 1637.9 1602.4
kup4k     Linux 2.6.34-    13.          11.1 1643.6 1604.2
kup4k     Linux 2.6.34-    13.          11.1 1639.7 1600.8

Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------
kup4k     Linux 2.6.34-  840.5 1304.3 4593.3 8703.0
kup4k     Linux 2.6.34-  843.5 1366.6 4601.7 8814.0
kup4k     Linux 2.6.34-  807.8 1377.5 4610.0 8710.0

Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------
kup4k     Linux 2.6.34- 1309.2 2235.2 3132.2  13.9K
kup4k     Linux 2.6.34- 1252.0 2339.0 2993.8  13.9K
kup4k     Linux 2.6.34- 1311.2 2335.2 2997.2  13.9K

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
kup4k     Linux 2.6.34-  131.8  144.7  130.8  168.4  207.8   190.7   248.1
kup4k     Linux 2.6.34-  129.4  142.4  140.8  186.4  211.1   187.0   257.9
kup4k     Linux 2.6.34-  121.3  155.6  131.0  196.8  201.5   198.5   240.7

*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
kup4k     Linux 2.6.34- 131.8 444.2 771. 1024.       1432.       3876
kup4k     Linux 2.6.34- 129.4 455.2 722. 1021.       1434.       3831
kup4k     Linux 2.6.34- 121.3 458.8 761. 1004.       1435.       3866

*Remote* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS   UDP  RPC/  TCP   RPC/ TCP
                               UDP         TCP  conn
--------- ------------- ----- ----- ----- ----- ----
kup4k     Linux 2.6.34-
kup4k     Linux 2.6.34-
kup4k     Linux 2.6.34-

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
kup4k     Linux 2.6.34-  16.7K  10.3K  90.9K  13.7K   22.6K  27.1    43.4 117.9
kup4k     Linux 2.6.34-  16.9K  15.6K 100.0K  16.1K   22.7K 9.590    39.8 119.2
kup4k     Linux 2.6.34-  16.7K  13.5K 100.0K  15.9K   22.8K 9.306    39.8 119.6

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
kup4k     Linux 2.6.34- 13.3 13.3 11.0   18.3   49.5   23.7   23.3 49.5  35.5
kup4k     Linux 2.6.34- 13.2 13.4 10.8   18.4   49.5   23.4   23.2 49.5  35.4
kup4k     Linux 2.6.34- 13.1 13.2 11.0   18.3   49.5   23.7   23.4 49.5  35.5

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
kup4k     Linux 2.6.34-    79   26.4  278.6       277.0      1145.6    No L2 cache?
kup4k     Linux 2.6.34-    79   26.4  278.7       277.1      1147.1    No L2 cache?
kup4k     Linux 2.6.34-    79   26.4  278.8       276.6      1146.9    No L2 cache?
make[1]: Leaving directory `/home/hs/lmbench-3.0-a9/results'
-bash-3.2#

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Heiko Schocher [off-list ref] wrote on 2011/01/21 07:53:02:

Hello Joakim,

Joakim Tjernlund wrote:

quoted

quoted

Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org

Rafael Beims [off-list ref] wrote on 2011/01/10 17:35:38:

quoted

quoted

Once you have tested it and it works, please send a patch to remove the 8xx workaround.
Make sure Scott is cc:ed

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
         /* On 8xx, cache control instructions (particularly
          * "dcbst" from flush_dcache_icache) fault as write
          * operation if there is an unpopulated TLB entry
          * for the address in question. To workaround that,
          * we invalidate the TLB here, thus avoiding dcbst
          * misbehaviour.
          */
         /* 8xx doesn't care about PID, size or ind args */
         _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */

Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.

Can you test these 2 patches on recent 2.6 linux:

quoted

From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:43:42 +0100
Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs

[...]

quoted

and

quoted

From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 11 Jan 2011 13:55:22 +0100
Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.

Tested this on a board similliar to the mainline tqm8xx board with
lmbench:

-bash-3.2# cat /proc/cpuinfo
processor       : 0
cpu             : 8xx
clock           : 80.000000MHz
revision        : 0.0 (pvr 0050 0000)
bogomips        : 10.00
timebase        : 5000000
platform        : KUP4K
model           : KUP4K
Memory          : 96 MB
-bash-3.2#

-bash-3.2# cat /proc/version
Linux version 2.6.34-00064-g3e81b6b (hs@pollux.denx.de) (gcc version 4.2.2) #89 Thu Jan 20 08:39:52 CET 2011
-bash-3.2#

(First run of lmbench without your 2 patches, the two other runs with it)

Thanks,

From a quick look, the only thing that really stands out is Prot Fault below:

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
kup4k     Linux 2.6.34-  16.7K  10.3K  90.9K  13.7K   22.6K  27.1    43.4 117.9
kup4k     Linux 2.6.34-  16.9K  15.6K 100.0K  16.1K   22.7K 9.590    39.8 119.2
kup4k     Linux 2.6.34-  16.7K  13.5K 100.0K  15.9K   22.8K 9.306    39.8 119.6

Anyhow, nothing broke so I am happy with the results.

On top of those 2 patches I came up with this cleanup patch too:

From 920c236b290ee00d84506369e3898126c78215e8 Mon Sep 17 00:00:00 2001

From: Joakim Tjernlund <redacted>
Date: Tue, 18 Jan 2011 09:50:09 +0100
Subject: [PATCH 3/3] powerpc: Use symbolic constants in 8xx TLB asm

Use the PTE #defines where possible instead of
hardcoded constants.

Signed-off-by: Joakim Tjernlund <redacted>
---
 arch/powerpc/kernel/head_8xx.S |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6cd99e2..31ed813 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S

@@ -451,11 +451,11 @@ DataStoreTLBMiss:
 	 * this into the Linux pgd/pmd and load it in the operation
 	 * above.
 	 */
-	rlwimi	r11, r10, 0, 27, 27
+	rlwimi	r11, r10, 0, _PAGE_GUARDED
 	/* 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
 	 */
-	rlwimi	r11, r10, 32-5, 30, 30
+	rlwimi	r11, r10, 32-5, _PAGE_WRITETHRU>>5
 	DO_8xx_CPU6(0x3b80, r3)
 	mtspr	SPRN_MD_TWC, r11

@@ -474,10 +474,10 @@ DataStoreTLBMiss:
 	rlwimi	r10, r11, 0, _PAGE_PRESENT
 #endif
 	/* Honour kernel RO, User NA */
-	/* 0x200 == Extended encoding, bit 22 */
-	rlwimi	r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
+	/* 0x200 == Encoding, bit 22 */
+	rlwimi	r10, r10, 32-2, _PAGE_USER>>2  /* Copy USER to Encoding */
 	/* r11 =  (r10 & _PAGE_RW) >> 1 */
-	rlwinm	r11, r10, 32-1, 0x200
+	rlwinm	r11, r10, 32-1, _PAGE_RW>>1
 	or	r10, r11, r10
 	/* invert RW and 0x200 bits */
 	xori	r10, r10, _PAGE_RW | 0x200
--

1.7.3.4