[Mesa-dev] [PATCH] os: add spinlocks

Thomas Hellstrom thellstrom at vmware.com
Wed Dec 15 04:20:17 PST 2010


On 12/15/2010 09:23 AM, Marek Olšák wrote:
> On Tue, Dec 14, 2010 at 8:10 PM, Thomas Hellstrom 
> <thellstrom at vmware.com <mailto:thellstrom at vmware.com>> wrote:
>
>     Hmm,
>
>     for the uninformed, where do we need to use spinlocks in gallium
>     and how do
>     we avoid using them on an UP system?
>
>
> I plan to use spinlocks to guard very simple code like the macro 
> remove_from_list, which might be, under some circumstances, called too 
> often. Entering and leaving a mutex is quite visible in callgrind.
>
> What does UP stand for?
>
> Marek

I've also noted that mutexes show up high on profiling on a number of 
occasions, but

Linux mutexes should theoretically be roughly as fast as spinlocks 
unless there is high contention. (They shouldn't call into the kernel 
unless there is contention). If this is not the case it is worth 
figuring out why.

The problem with spinlocks in user-space is that a context switch may 
occur in a locked section and that will have other processes trying to 
lock spinning until the process holding the lock is scheduled again.

On uni-processor (UP) systems spinlocks are particularly bad, since if 
there is contention on a lock, the process will always continue to spin 
until a timeout context switch, and thus behave much worse than a mutex  
which will context switch immediately.
(This is of course unless pthread spinlocks does some magic I'm not 
aware of)

In kernel space the situation is different, since spinlocks block 
preemption and contention can thus never occur on uniprocessor systems.

There are of course situations where user-space spinlocks are faster 
(high contention and low chance of context switch), but that really 
means the user needs to know exactly what he's doing and the drawbacks 
of using spinlocks.

I don't really think we should add spinlocks to gallium without

a) Figuring out why, in your case, mutexes behave so much worse than 
spinlocks. Do you expect high lock contention?
b) adding some kind of warning about the drawbacks of using them.

/Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101215/611de334/attachment.html>


More information about the mesa-dev mailing list