From: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
To: Dan Malek <dan@embeddededge•com>
Cc: Joakim.Tjernlund@lumentis•se, linuxppc-embedded@ozlabs•org
Subject: Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
Date: Sun, 24 Apr 2005 13:55:20 -0300 [thread overview]
Message-ID: <20050424165520.GA22786@logos.cnet> (raw)
In-Reply-To: <72ea00c21943f86d32f1a46a62ebc367@embeddededge.com>
Hi Dan, Joakim,
On Sat, Apr 23, 2005 at 08:00:39PM -0400, Dan Malek wrote:
>
> On Apr 23, 2005, at 7:51 PM, Joakim Tjernlund wrote:
>
> >hmm, I have more than 24MB of memory and I can run CONFIG_PIN_TLB just
> >fine with modules off in kernel 2.4. Havn't tried 2.6 yet.
>
> Doh. Oh, I see. We only do the optimization for the instruction
> misses.
> I'll have to take a closer look at Marcelo's 2.6 tests.
The PIN TLB entry option does not make much difference in my tests,
never did.
Who wrote the code? Are there results which indicate a performance gain
from TLB pinning on 8xx? If so, where are such results?
One problem that I've noted is that initial_mmu sets {I,D}TLB index
to be 27 (11100).
MI_RSV4I protects TLB's 27...31.
Given that both {I,D}TLB INDEX's are _decreased_ on each update, it seems
to me that initial_mmu should set {I,D}TLB INDEX to 31, which will then
decrease down to 27 after 4 TLB's are created.
Another question that comes to mind is why initial_mmu does create
additional 8Meg TLB entries for D-cache but not for I-cache:
#ifdef CONFIG_PIN_TLB
/* Map two more 8M kernel data pages.
*/
...
#endif
I'll do some more CONFIG_PIN_TLB tests this week...
--- head_8xx.S.orig2 2005-04-24 17:55:59.000000000 -0300
+++ head_8xx.S 2005-04-24 17:57:44.000000000 -0300
@@ -697,7 +697,7 @@
tlbia /* Invalidate all TLB entries */
#ifdef CONFIG_PIN_TLB
lis r8, MI_RSV4I@h
- ori r8, r8, 0x1c00
+ ori r8, r8, 0x1f00
#else
li r8, 0
#endif
@@ -705,7 +705,7 @@
#ifdef CONFIG_PIN_TLB
lis r10, (MD_RSV4I | MD_RESETVAL)@h
- ori r10, r10, 0x1c00
+ ori r10, r10, 0x1f00
mr r8, r10
#else
lis r10, MD_RESETVAL@h
next prev parent reply other threads:[~2005-04-24 22:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-23 17:23 [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses Joakim Tjernlund
2005-04-23 12:42 ` Marcelo Tosatti
2005-04-23 21:31 ` Joakim Tjernlund
2005-04-23 21:32 ` Dan Malek
2005-04-23 21:55 ` Joakim Tjernlund
2005-04-23 22:12 ` Dan Malek
2005-04-23 17:35 ` Joakim Tjernlund
2005-04-23 21:29 ` Dan Malek
2005-04-23 21:51 ` Joakim Tjernlund
2005-04-23 22:09 ` Dan Malek
2005-04-23 23:12 ` Dan Malek
2005-04-23 23:51 ` Joakim Tjernlund
2005-04-24 0:00 ` Dan Malek
2005-04-24 16:55 ` Marcelo Tosatti [this message]
2005-04-25 9:57 ` Joakim Tjernlund
2005-05-07 18:10 ` Joakim Tjernlund
2005-05-07 14:42 ` Marcelo Tosatti
2005-05-07 20:24 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2005-04-21 18:32 Marcelo Tosatti
2005-04-21 18:50 ` [26-devel] " Marcelo Tosatti
2005-04-22 6:18 ` Pantelis Antoniou
2005-04-22 15:39 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050424165520.GA22786@logos.cnet \
--to=marcelo.tosatti@cyclades$(echo .)com \
--cc=Joakim.Tjernlund@lumentis$(echo .)se \
--cc=dan@embeddededge$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox