SW TLB MMU rework and SMP issues (pte read/write)

Kumar Gala galak at kernel.crashing.org
Thu Jul 17 07:15:32 EST 2008


On Jul 16, 2008, at 3:57 PM, Kumar Gala wrote:

>>> * 64-bit PTEs and reader vs writer hazards.  How do we ensure that  
>>> the
>>> TLB miss handler samples a consistent view of the pte.  pte_updates
>>> seem ok since we only update the flag word.  However set_pte_at  
>>> seems
>>> like it could be problematic.
>>
>> eieio on the writer and a data dependency on the reader. segher
>> suggested a nice way to do it on the reader side, by doing a subf  
>> of the
>> value from the pointer and then a lwxz using that value as an offset.
>>
>> ie. something like that, with r3 containing the PTE pointer:
>>
>> 	lwz	r10,4(r3)
>> 	subf	r4,r10,r3  <-- you can use r3,r10,r3 if clobber is safe
>> 	lwzx	r11,r10,r4 <-- in which case you use r3 here too
>>
>> That ensures that the top half is loaded after the bottom half, which
>> is what you want if you do the set_pte_at() that way:
>>
>> 	stw	r11,0(r3)  <-- write top half first
>> 	eieio	           <-- maitain order to coherency domain
>>       stw	r10,4(r3)  <-- write bottom half last
>>
>> In fact, in the reader case, while at it, you can interleave that  
>> with
>> the testing of the present bit. Assuming _PAGE_PRESENT is in the low
>> bits and you can clobber r3, you get something like:
>>
>> 	lwz	r10,4(r3)
>> 	<-- can't do much here unless you can do unrelated things -->
>> 	andi.	r0,r10,_PAGE_PRESENT
>> 	subf	r3,r10,r3
>> 	beq	page_fault
>> 	lwzx	r11,r10,r3
>
> This makes sense.  I think we need to order the stores in set_pte_at  
> regardless of CONFIG_SMP.

Ok, so I realized that we don't actually need to order the stores  
since the sequential programming model will ensure the right things  
happens.

- k



More information about the Linuxppc-dev mailing list