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 <an...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
