Re: [PATCH] drm/gem: support BO freeing without dev->struct_mutex

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Alex Deucher <alexdeucher@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/gem: support BO freeing without dev->struct_mutex
Date: Wed, 27 Apr 2016 14:12:46 +0200	[thread overview]
Message-ID: <20160427121246.GD2558@phenom.ffwll.local> (raw)
In-Reply-To: <20160427115851.GA27856@nuc-i3427.alporthouse.com>

On Wed, Apr 27, 2016 at 12:58:51PM +0100, Chris Wilson wrote:
> On Wed, Apr 27, 2016 at 01:50:00PM +0200, Daniel Vetter wrote:
> > Finally all the core gem and a lot of drivers are entirely free of
> > dev->struct_mutex depencies, and we can start to have an entirely
> > lockless unref path.
> > 
> > To make sure that no one who touches the core code accidentally breaks
> > existing drivers which still require dev->struct_mutex I've made the
> > might_lock check unconditional.
> > 
> > While at it de-inline the ref/unref functions, they've become a bit
> > too big.
> > 
> > v2: Make it not leak like a sieve.
> > 
> > v3: Review from Lucas:
> > - drop != NULL in pointer checks.
> > - fixup copypasted kerneldoc to actually match the functions.
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Alex Deucher <alexdeucher@gmail.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_gem.c | 64 ++++++++++++++++++++++++++++++++++++++---------
> >  include/drm/drmP.h        | 15 ++++++++---
> >  include/drm/drm_gem.h     | 45 ++-------------------------------
> >  3 files changed, 66 insertions(+), 58 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 25dac31eef37..a4684a306c48 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -788,16 +788,7 @@ drm_gem_object_release(struct drm_gem_object *obj)
> >  }
> >  EXPORT_SYMBOL(drm_gem_object_release);
> >  
> > -/**
> > - * drm_gem_object_free - free a GEM object
> > - * @kref: kref of the object to free
> > - *
> > - * Called after the last reference to the object has been lost.
> > - * Must be called holding struct_ mutex
> > - *
> > - * Frees the object
> > - */
> > -void
> > +static void
> >  drm_gem_object_free(struct kref *kref)
> >  {
> >  	struct drm_gem_object *obj =
> > @@ -806,10 +797,59 @@ drm_gem_object_free(struct kref *kref)
> >  
> >  	WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> >  
> > -	if (dev->driver->gem_free_object != NULL)
> > +	if (dev->driver->gem_free_object_unlocked)
> > +		dev->driver->gem_free_object_unlocked(obj);
> > +	else if (dev->driver->gem_free_object)
> >  		dev->driver->gem_free_object(obj);
> >  }
> > -EXPORT_SYMBOL(drm_gem_object_free);
> 
> With my plan, I want to keep drm_gem_object_free exported.
> The plan being a __drm_gem_object_free_lockless fastpath.

Yeah, but I think we can reexport again in the patch that adds
__drm_gem_object_free_lockless. Just not much personally a friend of
sprawling EXPORT_SYMBOL when not needed. But I can drop that part too if
you feel strongly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel