Thanks for a lot of info. The more I think about spinlocks, the more I see they don't really give as much as I thought. I was just trying to optimize some code in a wrong way and probably at a wrong place too. It doesn't even deserve a comment as it was quite a banal thing.<br>
<br>FYI, I am not going to push the patch.<br><br>Marek<br><br><div class="gmail_quote">On Wed, Dec 15, 2010 at 4:10 PM, Thomas Hellstrom <span dir="ltr"><<a href="mailto:thellstrom@vmware.com" target="_blank">thellstrom@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
OK, Some info to back this up, please see inline.<div><br>
<br>
On 12/15/2010 01:20 PM, Thomas Hellstrom wrote:
<blockquote type="cite">
On 12/15/2010 09:23 AM, Marek Olšák wrote:
<blockquote type="cite">
<div class="gmail_quote">On Tue, Dec 14, 2010 at 8:10 PM, Thomas
Hellstrom <span dir="ltr"><<a href="mailto:thellstrom@vmware.com" target="_blank">thellstrom@vmware.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hmm,<br>
<br>
for the uninformed, where do we need to use spinlocks in gallium and
how do<br>
we avoid using them on an UP system?<br>
</blockquote>
<div><br>
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.<br>
<br>
What does UP stand for?<br>
<br>
Marek<br>
</div>
</div>
</blockquote>
<br>
I've also noted that mutexes show up high on profiling on a number of
occasions, but<br>
<br>
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.<br>
</blockquote>
<br></div>
At a first glance, looking at this article,<br>
<br>
<a href="http://www.alexonlinux.com/pthread-mutex-vs-pthread-spinlock" target="_blank">http://www.alexonlinux.com/pthread-mutex-vs-pthread-spinlock</a><br>
<br>
spinlocks should be superior for things like quick list manipulation,
but If I try that code with the second thread disabled (thus avoiding
lock contention), it turns out that in the uncontended case, spinlocks
are only some 13% faster.<div><br>
<br>
<blockquote type="cite"><br>
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.<br>
<br>
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. <br>
(This is of course unless pthread spinlocks does some magic I'm not
aware of)<br>
</blockquote>
<br>
<br></div>
Trying the code with two threads on a uni-processor desktop system,
spinlocks are some 63% slower than mutexes. This is with a kernel tick
of 1000HZ. Probably spinlock stats would be much worse with a slower
tick.<div><br>
<br>
<blockquote type="cite"><br>
In kernel space the situation is different, since spinlocks block
preemption and contention can thus never occur on uniprocessor systems.<br>
<br>
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.<br>
<br>
I don't really think we should add spinlocks to gallium without<br>
<br>
a) Figuring out why, in your case, mutexes behave so much worse than
spinlocks. Do you expect high lock contention?<br>
b) adding some kind of warning about the drawbacks of using them.<br>
</blockquote>
<br>
<br></div>
Finally, trying to repeat the author's findings on my dual-processor
system, Spinlocks are faster (but not nearly as much as the author
states, but that's probably because my CPUs are faster hence lower lock
contention), but the cpu-usage is roughly the same as in the mutex case.<br>
<br>
Given this, I would advise strongly against building spinlocks into any
code that might be run on a uni-processor system. Particularly gallium
utility code. <br>
If we want to get rid of unnecessary locking overhead we should
probably fix the code up to avoid taking the locks when not strictly
needed. <br>
<br>
/Thomas<br>
<br>
<blockquote type="cite"><br>
/Thomas<br>
<br>
</blockquote>
<br>
</div>
</blockquote></div><br>