All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Michel Thierry <michel.thierry@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: vma/ppgtt lifetime rules
Date: Tue, 29 Jul 2014 13:06:40 +0200	[thread overview]
Message-ID: <20140729110640.GQ4747@phenom.ffwll.local> (raw)
In-Reply-To: <1406628485-2415-1-git-send-email-michel.thierry@intel.com>

On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> VMAs should take a reference of the address space they use.
> 
> Now, when the fd is closed, it will release the ref that the context was
> holding, but it will still be referenced by any vmas that are still
> active.
> 
> ppgtt_release() should then only be called when the last thing referencing
> it releases the ref, and it can just call the base cleanup and free the
> ppgtt.
> 
> Signed-off-by: Michel Thierry <michel.thierry@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h         |  2 ++
>  drivers/gpu/drm/i915/i915_gem.c         |  8 ++++++++
>  drivers/gpu/drm/i915/i915_gem_context.c | 23 +++--------------------
>  drivers/gpu/drm/i915/i915_gem_gtt.c     |  5 +++++
>  4 files changed, 18 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2acc03f..a879a93 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
>  
>  /* i915_gem_context.c */
>  #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt, base)
> +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
>  int __must_check i915_gem_context_init(struct drm_device *dev);
> +void ppgtt_release(struct kref *kref);
>  void i915_gem_context_fini(struct drm_device *dev);
>  void i915_gem_context_reset(struct drm_device *dev);
>  int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dcd8d7b..25a32b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
>  
>  void i915_gem_vma_destroy(struct i915_vma *vma)
>  {
> +	struct i915_address_space *vm = NULL;
> +	struct i915_hw_ppgtt *ppgtt = NULL;
>  	WARN_ON(vma->node.allocated);
>  
>  	/* Keep the vma as a placeholder in the execbuffer reservation lists */
>  	if (!list_empty(&vma->exec_list))
>  		return;
>  
> +	vm = vma->vm;
> +	ppgtt = vm_to_ppgtt(vm);
> +
> +	if (ppgtt)
> +		kref_put(&ppgtt->ref, ppgtt_release);

Hm, this has the risk that we leave unwanted vmas around for a bit longer.
They will get cleaned up though when the final object references goes
away, so the leak is fairly restricted. And currently we don't have a
shrinker to just whack out vma objects even ...

It's definitely a much neater solution than what I had in mind with moving
vmas to full-blown active tracking like we do objects. So I'm tempted to
go with, but have a bit a lurking feeling that I'm missing something.

Chris?

Cheers, Daniel

> +
>  	list_del(&vma->vma_link);
>  
>  	kfree(vma);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5b5af6c..59272f9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
>  		return;
>  	}
>  
> -	/*
> -	 * Make sure vmas are unbound before we take down the drm_mm
> -	 *
> -	 * FIXME: Proper refcounting should take care of this, this shouldn't be
> -	 * needed at all.
> -	 */
> -	if (!list_empty(&vm->active_list)) {
> -		struct i915_vma *vma;
> -
> -		list_for_each_entry(vma, &vm->active_list, mm_list)
> -			if (WARN_ON(list_empty(&vma->vma_link) ||
> -				    list_is_singular(&vma->vma_link)))
> -				break;
> -
> -		i915_gem_evict_vm(&ppgtt->base, true);
> -	} else {
> -		i915_gem_retire_requests(dev);
> -		i915_gem_evict_vm(&ppgtt->base, false);
> -	}
> +	/* vmas should already be unbound */
> +	WARN_ON(!list_empty(&vm->active_list));
>  
>  	ppgtt->base.cleanup(&ppgtt->base);
>  }
>  
> -static void ppgtt_release(struct kref *kref)
> +void ppgtt_release(struct kref *kref)
>  {
>  	struct i915_hw_ppgtt *ppgtt =
>  		container_of(kref, struct i915_hw_ppgtt, ref);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 1411613..90c3d0f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
>  				  struct i915_address_space *vm)
>  {
>  	struct i915_vma *vma;
> +	struct i915_hw_ppgtt *ppgtt = NULL;
>  
>  	vma = i915_gem_obj_to_vma(obj, vm);
>  	if (!vma)
>  		vma = __i915_gem_vma_create(obj, vm);
>  
> +	ppgtt = vm_to_ppgtt(vm);
> +	if (ppgtt)
> +		kref_get(&ppgtt->ref);
> +
>  	return vma;
>  }
> -- 
> 1.9.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-07-29 11:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 10:08 [PATCH] drm/i915: vma/ppgtt lifetime rules Michel Thierry
2014-07-29 11:06 ` Daniel Vetter [this message]
2014-07-29 11:19   ` Chris Wilson
2014-07-29 18:32 ` Ben Widawsky
2014-07-29 18:44   ` Ben Widawsky
2014-07-29 19:19     ` Daniel Vetter
2014-07-30  8:19       ` Thierry, Michel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140729110640.GQ4747@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michel.thierry@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.