[PATCH] powerpc: Use lwarx hint bit in spinlocks

Kumar Gala galak at kernel.crashing.org
Thu Feb 11 02:40:34 EST 2010


On Feb 9, 2010, at 9:19 PM, Josh Boyer wrote:

> On Wed, Feb 10, 2010 at 01:50:11PM +1100, Anton Blanchard wrote:
>> 
>> Recent versions of the PowerPC architecture added a hint bit to the larx
>> instructions to differentiate between an atomic operation and a lock operation:
>> 
>>> 0 Other programs might attempt to modify the word in storage addressed by EA
>>> even if the subsequent Store Conditional succeeds.
>>> 
>>> 1 Other programs will not attempt to modify the word in storage addressed by
>>> EA until the program that has acquired the lock performs a subsequent store
>>> releasing the lock.
>> 
>> To avoid a binutils dependency this patch create macros for the extended lwarx
>> format and uses it in the spinlock code. To test this change I used a simple
>> test case that acquires and releases a global pthread mutex:
>> 
>> 	pthread_mutex_lock(&mutex);
>> 	pthread_mutex_unlock(&mutex);
>> 
>> On a 32 core POWER6 running 32 test threads we spend almost all our time in
>> the futex spinlock code (as expected):
>> 
>>   94.37%     perf  [kernel]                     [k] ._raw_spin_lock
>>              |          
>>              |--99.95%-- ._raw_spin_lock
>>              |          |          
>>              |          |--63.29%-- .futex_wake
>>              |          |          
>>              |          |--36.64%-- .futex_wait_setup
>> 
>> which is a good test for this patch. The results (in lock/unlock operations
>> per second) are:
>> 
>> before: 1538203 ops/sec
>> after:  2189219 ops/sec
>> 
>> An improvement of 42%
>> 
>> Signed-off-by: Anton Blanchard <anton at samba.org>
>> ---
>> 
>> We've had issues in the past with chips that do the wrong thing and don't
>> ignore instruction reserved bits. One option might be to limit this change to
>> 64bit and verify on that limited set of CPUs.
> 
> In the off chance that someone actually does an SMP 44x, I think the hint bit
> here would just be ignored (I could test possibly if we want to verify).
> However, I thought the FSL parts didn't like toggling the reserved bits and
> those already are SMP in some cases.
> 
> Kumar?
> 
> josh

Yeah, I need to test this on some older SMP parts that didn't treated reserved bits being set in the opcode as ignored but illegal.

- k


More information about the Linuxppc-dev mailing list