Re: [PATCH] drm/i915/execlists: Use a local lock for dfs_link access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 17, 2016 at 08:52:59AM +0000, Chris Wilson wrote:
> On Thu, Nov 17, 2016 at 09:45:17AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 16, 2016 at 04:03:27PM +0000, Chris Wilson wrote:
> > > On Wed, Nov 16, 2016 at 03:54:23PM +0000, Tvrtko Ursulin wrote:
> > > > 
> > > > On 16/11/2016 15:27, Chris Wilson wrote:
> > > > >Avoid requiring struct_mutex for exclusive access to the temporary
> > > > >dfs_link inside the i915_dependency as not all callers may want to touch
> > > > >struct_mutex. So rather than force them to take a highly contended
> > > > >lock, introduce a local lock for the execlists schedule operation.
> > > > >
> > > > >Reported-by: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx>
> > > > >Fixes: 9a151987d709 ("drm/i915: Add execution priority boosting for mmioflips")
> > > > 
> > > > Grumble grumble, sloppy review. :I
> > > 
> > > Too busy living the good life with working atomic flips.
> > >  
> > > > >Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > > >Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > > > >Cc: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx>
> > > > >---
> > > > > drivers/gpu/drm/i915/intel_lrc.c | 7 +++++--
> > > > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > > > >
> > > > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> > > > >index e23b6a2600fb..10e59ff0d8f1 100644
> > > > >--- a/drivers/gpu/drm/i915/intel_lrc.c
> > > > >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > > >@@ -694,6 +694,7 @@ pt_lock_engine(struct i915_priotree *pt, struct intel_engine_cs *locked)
> > > > >
> > > > > static void execlists_schedule(struct drm_i915_gem_request *request, int prio)
> > > > > {
> > > > >+	static DEFINE_MUTEX(lock);
> > > > 
> > > > Good enough for one GPU. :) Consider improving in the future as it
> > > > is not in the spirit of the driver.
> > > 
> > > Actually... Being able to PI across multiple GPUs is part of the dream.
> > > In that case, it does need to be a global lock - just a bit iffy on
> > > getting dependency tracking into a common layer.
> > 
> > Why exactly does this need a global lock? And yes static mutex in a
> > function looks evil, pls move right next to the data.
> 
> It is next to the data.

diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h
index e2b077df2da0..c7c4c465adce 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -44,10 +44,13 @@ struct intel_signal_node {
 	struct intel_wait wait;
 };
 
+extern struct mutex dfs_lock;
+
 struct i915_dependency {
 	struct i915_priotree *signaler;
 	struct list_head signal_link;
 	struct list_head wait_link;
+	/* protected by dfs_lock */
 	struct list_head dfs_link;
 	unsigned long flags;
 #define I915_DEPENDENCY_ALLOC BIT(0)

Or something like that. Or at least a note about this stuff.

Oh and broken record again: Any plans to kernel-doc all the fancy new
stuff (datastructures and interface functions), or is that not on the
plan?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux