[PATCH][RFC] unlikely spinlocks

[Sonny Rao]

On Wed, Mar 02, 2005 at 04:34:12PM -0600, Jake Moilanen wrote:
> 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

Hmm, I doubt you want to use specjbb to show spin-lock contention.

Unless I'm missing something, jbb scales really well in terms of the
kernel, most of the benchmark runs in userspace and the JVM's
own locking strategies probably have a bigger impact on performance
than the kernel's _raw_spin_lock() implementation.  I should probably
have Java Perf. guys get oprofile data for jbb to confirm this
conclusively. 

If you use FFSB with enough threads doing lots of file-descriptor
activity, you'll see tons of lock contention on the fget_light
function.  This is a pretty well known scalability problem, and I've
been able to drive my 16-way LPAR to  > 40% spin_lock time doing
things like this with FFSB and tons of threads.

Sonny