On Mar 22, 2005, at 12:58 PM, Marcelo Tosatti wrote:

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 ?

Nothing.  In fact, they are likely invalidated shortly after the kernel
page tables are set up.  This was only done to ensure we could get the
kernel initialized without taking page faults.

By a counter at the end of _tlbie function, similar to other counters 
which
you suggested.

OK.

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.

Hmmm ...  Then, the 2.6 looks to be much less efficient with the MMU
resources than 2.4 was.  This is going to affect everyone, it's just 
easier
to measure on this processor.

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):

What is your guess?  I don't know how this would reduce the number
of tlbie instructions, since stealing a context (as part of 
get_context())
will simply whack the whole TLB with a tlbia.  On 8xx, both instructions
could be simply implemented as macros.

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.

:-)

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.

Well, that's interesting.  It's likely to only happen on an 860 variant 
that
has the large TLB.

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

It used to happen on early 2.6 versions as soon as you entered user
space programs.


	-- Dan