[PATCH 2.6.14] mm: 8xx MM fix for

[Pantelis Antoniou]

On Monday 07 November 2005 22:39, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
> 
> > 
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
> 
> I see, so you are in the same situation as ia64 which has valid but
> unmapped TLBs ?
> 
> > Dan, I wonder why we just don't go back to v2.4 behaviour. It is not very
> > clear to me that "two exception" speedup offsets the additional code required
> > for "one exception" version. Have you actually done any measurements? 
> 
> What do you mean by "one exception" version ? You probably get 3 in fact
> since after you have serviced the fault in the common code, you take
> another fault to fill the PTE.
> 
> In fact, you could even go back to one exception by pre-filling the TLB
> in update_mmu_cache :)
> 

Yep. That should be the target. Remember the poor 8xx is not exactly a 
speed demon :).

> > There is chance that the additional code ends up in the same cacheline,
> > which would mean no huge gain by the "two exception" approach. Might be
> > even harmful for performance (you need two exceptions instead of one
> > after all).
> > 
> > The "two exception" approach requires a TLB flush (to nuke the zeroed)
> > at each PTE update for correct behaviour (which BTW is another slowdown):
> 
> I think the current code, even with your fix, is sub-optimal. But of
> course, the only way to be sure is to do real measurements
> 
> Ben.
> 
> 

The TLB flush is bogus IMO. I'm going to try the last patch by marcelo to
see if it works for me.

Pantelis.