svn commit: r190704 - head/sys/powerpc/aim

[Marcel Moolenaar]

On Apr 5, 2009, at 2:03 AM, Rafal Jaworowski wrote:

>> Log:
>> Perform a dummy stwcx. when we switch contexts. The context
>> being switched out may hold a reservation. The stwcx. will
>> clear the reservation. This is architecturally recommended.
>>
>> The scenario this addresses is as follows:
>> 1. Thread 1 performs a lwarx and as such holds a reservation.
>> 2. Thread 1 gets switched out (before doing the matching
>>    stwcx.) and thread 2 is switched in.
>> 3. Thread 2 performs a stwcx. to the same reservation granule.
>>    This will succeed because the processor has the reservation
>>    even though thread 2 didn't do the lwarx.
>>
>> Note that on some processors the address given the stwcx. is
>> not checked. On these processors the mere condition of having
>> a reservation would cause the stwcx. to succeed, irrespective
>> of whether the addresses are the same. The dummy stwcx. is
>> especially important for those processors.
>
> Have you seen this false stwcx. actually succeed in some real  
> scenarios on AIM? Were there any tangible [corruption?] effects  
> observed without this fix?

I think so, but I may be mistaken easily. I've been running with
this for a while on my SMP machine and it "felt" more stable.
make release for example would always end with sh(1) dumping core.
I don't see that anymore.

> We're seeing some hang with the dual E500 under very heavy loads,  
> but only with ULE (or we could only correlate this with ULE so far),  
> but didn't get to really close investigation of this issue yet. I'm  
> wondering if it's something of this sort too.

It's not impossible. I can only say: try it :-)

-- 
Marcel Moolenaar
xcllnt at mac.com