On Wed, 2010-12-15 at 09:19 -0800, Kristian Høgsberg wrote: > 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".
I think one thing that's going on here is we've made it too easy to share objects between threads/contexts, or perhaps too hard to create context-private objects. Before making more guesses though I'd be interested to get more information about what these locks are protecting & what the circumstances are. Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev