[26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses

[Joakim Tjernlund]

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

Don't your TLB Miss counters look different for kernel space? If they don't there must be something
very wrong with the CONFIG_PIN_TLB code.

> 
> Who wrote the code? Are there results which indicate a performance gain
> from TLB pinning on 8xx? If so, where are such results? 

I think Dan wrote this code. In 2.4 I improved the ITLB Miss handler a little for
pinned ITLBs

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

Makes sense but I can't say for sure. I tried the patch below on my 2.4 tree
and it works fine.

> 
> Another question that comes to mind is why initial_mmu does create 
> additional 8Meg TLB entries for D-cache but not for I-cache:

Because the kernel code will never grow beyond 8MB, but data will due
to kmalloc() etc.

[SNIP]