<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=us-ascii">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Marcelo Tosatti wrote:<br>
<blockquote type="cite" cite="mid20050322175815.GB7846@logos.cnet">
  <pre wrap="">On Tue, Mar 22, 2005 at 03:57:08PM -0500, Dan Malek wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
less times than v2.4 ?
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
That was rather a _factor_ of "100-or-so" less.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Oh my ...  I'm more worried about the high number of TLB misses
in 2.6 compared to 2.4.  That's really bad.  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Newbie question: What prevents the initial kernel map (tuple of 8Mbyte I/D-TLB entries) 
and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation pressure,
in case CONFIG_PIN_TLB is disabled ? 

  </pre>
  <blockquote type="cite">
    <pre wrap="">How did you instrument the tlbie measurement? 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
By a counter at the end of _tlbie function, similar to other counters which 
you suggested.

  </pre>
  <blockquote type="cite">
    <pre wrap="">It could be that 2.4 used lots more 'tlbia' which were replaced by tlbie in 2.6.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Dont think thats the case given that v2.4 calls tlbia through flush_tlb_mm() at exit_mmap() 
only. And at vmalloc_free which shouldnt be called at all.

I just noticed this conditional at switch_mm() (v2.6), which _can_ partly 
explain the reduced tlbie's  (its just a guess for now, though):

static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
                             struct task_struct *tsk)
{
#ifdef CONFIG_ALTIVEC
        asm volatile (
 BEGIN_FTR_SECTION
        "dssall;\n"
#ifndef CONFIG_POWER4
         "sync;\n" /* G4 needs a sync here, G5 apparently not */
#endif
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
         : : );
#endif /* CONFIG_ALTIVEC */
                                                                                            
        tsk-&gt;thread.pgdir = next-&gt;pgd;
                                                                                            
        /* No need to flush userspace segments if the mm doesnt change */
        if (prev == next)                                 &lt;--------------
                return;                                   &lt;--------------
                                                                                            
        /* Setup new userspace context */
        get_mmu_context(next);
        set_context(next-&gt;context, next-&gt;pgd);
}

I'm about to disable it and retry.

Spent part of the day reading the MMU section of 860 manual, I think I have kind 
of a clue how things are supposed to work at the lowlevel now. 

I'll continue tracking it down - any help is appreciated.

PS: I can't reproduce the invalid TLB crash anymore. i.e. even by removing
the _tlbie() at update_mmu_cache() everything is working as expected.

How can I reproduce it again? Guillaume, what kernel version are you using?

  </pre>
</blockquote>
It is very timing dependant. Running 2.6.11, ldconfig crashes in
__flush_dcache_icache(...) just after boot time (first time called).
Unfortunatly, it only happens every now and then. And of course, never
when my BDI2000 is plugged in. :(<br>
<br>
I also noticed that with kernel preemption disable, oops are less
frequent. Probably does not mean anything anyway...<br>
<br>
Guillaume.<br>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:gautran@mrv.com">gautran@mrv.com</a>
======================================= </pre>
</body>
</html>