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:

quoted

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