diff options
author | Anton Blanchard <anton@samba.org> | 2010-02-10 01:10:25 +0000 |
---|---|---|
committer | Benjamin Herrenschmidt <benh@kernel.crashing.org> | 2010-02-17 14:03:16 +1100 |
commit | 5a0e9b5718d921f5d8e17176d6b483f6b8f1844a (patch) | |
tree | ce0e0eab2d6fc06d4215c974ead0d98fe85d73f0 /lib/libcrc32c.c | |
parent | 53eae2281ad2607fa66a8ad1cb06186c8900da56 (diff) | |
download | linux-3.10-5a0e9b5718d921f5d8e17176d6b483f6b8f1844a.tar.gz linux-3.10-5a0e9b5718d921f5d8e17176d6b483f6b8f1844a.tar.bz2 linux-3.10-5a0e9b5718d921f5d8e17176d6b483f6b8f1844a.zip |
powerpc: Use lwsync for acquire barrier if CPU supports it
Nick Piggin discovered that lwsync barriers around locks were faster than isync
on 970. That was a long time ago and I completely dropped the ball in testing
his patches across other ppc64 processors.
Turns out the idea helps on other chips. Using a microbenchmark that
uses a lot of threads to contend on a global pthread mutex (and therefore a
global futex), POWER6 improves 8% and POWER7 improves 2%. I checked POWER5
and while I couldn't measure an improvement, there was no regression.
This patch uses the lwsync patching code to replace the isyncs with lwsyncs
on CPUs that support the instruction. We were marking POWER3 and RS64 as lwsync
capable but in reality they treat it as a full sync (ie slow). Remove the
CPU_FTR_LWSYNC bit from these CPUs so they continue to use the faster isync
method.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Diffstat (limited to 'lib/libcrc32c.c')
0 files changed, 0 insertions, 0 deletions