Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Mon, Mar 21, 2005 at 04:45:21PM -0500, Guillaume Autran wrote:
> Hi,
> 
> Was there any progress made about this issue or is it still pending ? 

That one is still pending.

There are other issues in 8xx which are probably related to it, as follows. 

> I'm running 2.6.11 and still see the problem...

I'm currently trying to understand 8xx cache structure and VM semantics to 
find out why I'm seeing the following numbers. 

Test application is: copy 16M from /dev/zero to file-on-RAMDISK, using:
# dd if=/dev/zero of=file bs=4k count=3840 

v2.6:
                                                                      
I-TLB userspace misses: 141264
I-TLB kernel misses: 117455
D-TLB userspace misses: 217590
D-TLB kernel misses: 202677
tlbie: 260
 
I-TLB userspace misses: 143455
I-TLB kernel misses: 119189
D-TLB userspace misses: 212828
D-TLB kernel misses: 197883
tlbie: 260
 
I-TLB userspace misses: 142248
I-TLB kernel misses: 118195
D-TLB userspace misses: 217576
D-TLB kernel misses: 202663
tlbie: 260

v2.4: 
 
I-TLB userspace misses: 266
I-TLB kernel misses: 5170
D-TLB userspace misses: 3661
D-TLB kernel misses: 177004
tlbie: 162599
 
I-TLB userspace misses: 266
I-TLB kernel misses: 3183
D-TLB userspace misses: 2024
D-TLB kernel misses: 180178
tlbie: 165675

I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
less times than v2.4 ?

Paul, Ben? 

> 
> Regards,
> Guillaume.
> 
> 
> 
> Marcelo Tosatti wrote:
> 
> >On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
> > 
> >
> >>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
> >>   
> >>
> >>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
> >>>
> >>>     
> >>>
> >>>>Does anyone have a clue of what is/can be wrong with the TLB entry for 
> >>>>the
> >>>>address being flushed at __flush_dcache_icache()?
> >>>>       
> >>>>
> >>>Not sure.  The problem is that the __flush_dcache_icache is passed a
> >>>user space virtual address that doesn't look like it is mapped for 
> >>>writing
> >>>or something.  I don't know, as an ooops isn't sufficient to debug the 
> >>>problem.
> >>>You have to catch it here and track down the current state of the TLB 
> >>>and
> >>>the page tables.  Of course, when I do this everything looks OK, 
> >>>     
> >>>
> >>How do you do track down the current TLB state? With a BDI? 
> >>
> >>   
> >>
> >>>so what I've been trying to do is catch the TLBmiss reload that actually 
> >>>causes this
> >>>to happen to see what it really tried to load into the tlb.
> >>>     
> >>>
> >>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to 
> >>your
> >>analysis ?? 
> >>   
> >>
> >
> >So this assumption which you have made sometime ago is wrong, given that 
> >now you know TLB entry is not stale ?
> >
> >"The symptom is we appear to have a stale TLB entry,
> >so at least one of the callouts from the generic VM
> >code isn't doing the right thing for us.  I'm still
> >puzzled as to why it doesn't affect other PPC processor." 
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded at ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > 
> >
> 
> -- 
> =======================================
> Guillaume Autran
> Senior Software Engineer
> MRV Communications, Inc.
> Tel: (978) 952-4932 office
> E-mail: gautran at mrv.com
> ======================================= 
>