On our raw spinlocks, we currently have an attempt at the lock, and if we do
not get it we enter a spin loop.  This spinloop will likely continue for
awhile, and we pridict likely.

Shouldn't we predict that we will get out of the loop so our next instructions
are already prefetched.  Even when we miss because the lock is still held, it
won't matter since we are waiting anyways.

I did a couple quick benchmarks, but the results are inconclusive.

	16-way 690 running specjbb with original code
	# ./specjbb 3000 16 1 1 19 30 120
	    ...
	Valid run, Score is 59282

	16-way 690 running specjbb with unlikely code
	# ./specjbb 3000 16 1 1 19 30 120
	    ...
	Valid run, Score is 59541

I saw a smaller increase on a JS20 (~1.6%)

	JS20 specjbb w/ original code
	# ./specjbb 400 2 1 1 19 30 120
	   ...
	Valid run, Score is 20460

	JS20 specjbb w/ unlikely code
	# ./specjbb 400 2 1 1 19 30 120
	   ...
	Valid run, Score is 20803

Anton said:

Mispredicting the spinlock busy loop also means we slow down the rate at which
we do the loads which can be good for heavily contended locks.

Note: There are some gcc issues with our default build and branch prediction,
but a CONFIG_POWER4_ONLY build should emit them correctly.  I'm working with
Alan Modra on it now.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>