Re: i386 spinlock fairness: bizarre test results

From: Joe Seigh
Date: Tue Oct 11 2005 - 07:32:36 EST

Robert Hancock wrote:
Chuck Ebbert wrote:

After seeing Kirill's message about spinlocks I decided to do my own
testing with the userspace program below; the results were very strange.

When using the 'mov' instruction to do the unlock I was able to reproduce
hogging of the spinlock by a single CPU even on Pentium II under some
conditions, while using 'xchg' always allowed the other CPU to get the

This might not necessarily be a win in all situations. If two CPUs A and B are trying to get into a spinlock-protected critical section to do 5 operations, it may well be more efficient for them to do AAAAABBBBB as opposed to ABABABABAB, as the second situation may result in cache lines bouncing between the two CPUs each time, etc.

I don't know that making spinlocks "fairer" is really very worthwhile. If some spinlocks are so heavily contented that fairness becomes an issue, it would be better to find a way to reduce that contention.

You're right that it wouldn't be an issue on a system with relatively few
cpu's since that amount of contention would cripple the system. Though
with 100's of cpu's you could get contention hotspots with some spin locks
being concurrently accessed by some subset of the cpu's for periods of time.

The real issue is scalability or how gracefully does a system degrade
when it starts to hit its contention limits. It's not a good thing when
a system appears to run fine and then catastrophically hangs when it
bumps across its critical limit. It's better when a system exhibit's
some sort of linear degradation. The former exhibits bistable behavior
which requires a drastic, probably impossible, reduction in work load
to regain normal performance. Reboots are the normal course of correction.
The linearly degrading systems just require moderation of the workload
to move back into acceptable performance.

Anyway, if you want to build a scalable system, it makes sense to build it
out of scalable components. Right?

Joe Seigh

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at