On Mon, Aug 22, 2016 at 02:21:16PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-22 at 09:03 +0100, Chris Wilson wrote: > > This is a golden oldie! We can shave a couple of locked instructions for > > about 10% of the per-object overhead by not taking an extra kref whilst > > reserving objects for an execbuf. Due to lock management this is safe, > > as we cannot lose the original object reference without the lock. > > Equally, because this relies on the heavy BKL^W struct_mutex, it is also > > likely to be only a temporary optimisation until we have fine grained > > locking. (That's what we said 5 years ago, so there's probably another > > 10 years before we get around to finer grained locking!) > > > > Should we sprinkle a couple of lockdep_assert_held for documentation? What's required is a struct mutex.serial counter so that we can assert that the mutex wasn't unlocked since the lookup and before use. i915_gem_execbuffer.c is pretty much self-contained (and will be even more so in future) and the place where we drop the lock is scary enough to carry lots of comments. I tend to focus the asserts on the boundaries between pieces of code, but I'll have a look to see if there are sensible places within execbuf that merit a sprinkling of lockdep asserts. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
