[PATCH][RFC] unlikely spinlocks

Joel Schopp jschopp at austin.ibm.com
Thu Mar 3 11:55:47 EST 2005


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 agree with you in principle.  It would be nice to have some better 
supporting measurements as well though.

> 
> 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%)

Percentage wise the 690 increase was smaller

> 
> 	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
> 
> Jake

My guess is there is some variance in specjbb runs.  The variance might 
be greater than the amount of improvement.  It is still possible to use 
statistics to show the amount of the increase.  If you could get me the 
results of say 12 runs on each kernel I could do the analysis for you.

On a side note.  Do you have the assembly generated by _raw_spin_lock() 
and brethren?  They always get inlined so I doubt a simple objdump would 
do it.  I'm curious how good the compiler is at optimizing away things.



More information about the Linuxppc64-dev mailing list