On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote: > However, drm_intel_bo_reference/unreference() is showing up on the > profiles now that relocations are cheaper, but I think the better way > to make those cheaper is to move the ref count to the public struct > and make the ref/unref inline functions (calling out to a destructor > for the refcount==0 case, of course). On that note, do you know why > drm_intel_gem_bo_unreference() is so convoluted? What's the deal with > the atomic_add_unless? Yeah, it's the optimised way to do an unref that then requires taking a mutex. Releasing the last reference to the object is only threadsafe under the mutex (otherwise another thread may preempt us, acquire the ref and release it all before the first thread processes the free and decouple it from the lists), but we want to avoid taking the mutex until necessary. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
