public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
To: Joakim Tjernlund <Joakim.Tjernlund@lumentis•se>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
Date: Sat, 7 May 2005 11:42:24 -0300	[thread overview]
Message-ID: <20050507144224.GD16996@logos.cnet> (raw)
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHGEJMCLAA.Joakim.Tjernlund@lumentis.se>

On Sat, May 07, 2005 at 08:10:38PM +0200, Joakim Tjernlund wrote:
> > 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
> 
> Not completly sure that this is correct. There are a few:
> 	addi	r10, r10, 0x0100
>  	mtspr	SPRN_MD_CTR, r10
> later on which will "overflow" 0x1f00 into 0x2000 etc.

Yep. This is not correct at all: the TLB index is increased 
at each miss, not decreased as the manual says. 

I have confirmed it with the BDI... 

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

  reply	other threads:[~2005-05-07 19:24 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
2005-04-25  9:57         ` Joakim Tjernlund
2005-05-07 18:10         ` Joakim Tjernlund
2005-05-07 14:42           ` Marcelo Tosatti [this message]
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=20050507144224.GD16996@logos.cnet \
    --to=marcelo.tosatti@cyclades$(echo .)com \
    --cc=Joakim.Tjernlund@lumentis$(echo .)se \
    --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