On Wed, Dec 15, 2010 at 10:10 AM, Thomas Hellstrom <thellst...@vmware.com> wrote: ... > 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. > 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.
Another option is to rethink/refactor the code in question to just take the locks less. Use per thread (context) state instead where possible and batch updates to global state so you can take the lock and do a bunch of stuff. For example, if you're putting many items back on a global free list, just put them back on a local free list one by one, and then take the lock and then merge the thread local free list into the global list (should be a constant time operation) eventually. I know it's easier said than done, but if locking is showing up on the profile, I think "use less locking" is a better fix than "use faster locking". Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
