[Intel-gfx] [PATCH 01/17] drm/i915: Skip holding an object reference for execbuf preparation
Chris Wilson
chris at chris-wilson.co.uk
Mon Aug 22 11:56:43 UTC 2016
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
More information about the Intel-gfx
mailing list