fsl booke MM vs. SMP questions

[Gabriel Paubert]

On Tue, May 22, 2007 at 08:05:42PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-22 at 12:02 +0200, Gabriel Paubert wrote:
> > 
> > Well, there should always be an stwcx. to clear reservation before
> > any interrupt return. Otherwise you'll be able to cause hard to
> > reproduce bugs in the interrupted code.
> 
> Well, that's the point. The BookE TLB refill exception is a very fast
> path that doesn't use the normal interrupt return code path. It thus
> needs to be careful about not leaving dangling reservations.

Ok, thanks. I missed that critical piece of information from
the context. In this case it makes sense, although I wonder
if a different order of instructions could shave some latency 
from the critical path:

	 1 - rX = read PTE value (normal load)
	 2 - if (!_PAGE_PRESENT)) -> out
 	 3 - rY = rX | _PAGE_ACCESSED
	 4 - if (rX != rY)
	
Specifically here, I wonder whether instead of the sequence:
	ori	ry, rx, PAGE_ACCESSED
	cmpw	rx, ry
	beq	11f	; Needs non-default static prediction?


it might be better to write it as:
	andi.	rz, rx, PAGE_ACCESSED
	ori	ry, rx, PAGE_ACCESSED
	bne	11f

since on some processors the branch might be resolved one cycle
earlier. But I don't know very well the processors with these MMU.

	 5 -   rZ = lwarx PTE value
	 6 -   if (rZ != rX)
	 7 -	stdcx. PTE, rZ (rewrite just read value to clear reserv)

Hmm, lWarx paired with stDcx., looks like a typo ?

	 8 - 	goto 1 (try again)
	 9 -   stdcx. PTE, rY 
Ditto.
	10 -   if failed -> goto 1 (try again)
	11 - that's it ! 

I suspect that in the TLB handler, you've got something
like 4 registers and one CR field to play with. So more
clever solutions may be impossible to implement.

> On some CPUs, there are also performance issues with leaving dangling
> lwarx iirc but I don't have the details off the top of my mind.
> 

I don't know of any, but I almost exclusively use 603e and 750.


	Gabriel