Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote: > On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote: > > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote: > > > On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote: > > > > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com > > > > wrote: > > > > > From: Rafael Barbalho > > > > > > > > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs > > > > > to be > > > > > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > > > > > > > > > This problem only shows up with full PPGTT because an object's VMA is > > > > > only cleaned-up when the object is destroyed. However, if the object > > > > > has > > > > > been shared between multiple processes this may not happen, which > > > > > leads to > > > > > references to the PPGTT still being kept the object was shared. > > > > > > > > > > Under android the sharing of GEM objects is a fairly common > > > > > operation, thus > > > > > the clean-up has to be more agressive. > > > > > > > > Not quite. You need an active refcount as we do not expect close(fd) to > > > > stall. The trick is to "simply" use requests to retire vma (as well as > > > > the object management it does today, though that just becomes a second > > > > layer for GEM API management, everything else goes through vma). > > > > > > Linking into the ctx unref should give us that for free since requests do > > > hold a reference on the context. So this will only be run when the buffers > > > are idle. > > > > > > Well except that our unbind code is too dense to do that correctly for > > > shared buffers, so we need to move obj->active to vma->active first. > > > > We unbind vma, so what do you mean? > > The unbind of the vma will block since we track active per-obj instead of > per-vma. Which is kinda not that cool for a kref_put cleanup function. > > But yeah the below is what I had in mind too, with the mentioned nuisance > fixed. Oh and there's a fun bit of code to clean up - in the execbuf code we just pin the 2nd vma for the ggtt, which crucially relies on the ->active boolean being shared by all vmas. That needs to be fixed first before we can move obj->active to vma->active. For context see commit da51a1e7e398129d9fddd4b26b8469145dd4fd08 Author: Daniel Vetter Date: Mon Aug 11 12:08:58 2014 +0200 drm/i915: Fix secure dispatch with full ppgtt Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Mon, Feb 23, 2015 at 04:52:46PM +, Barbalho, Rafael wrote: > > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Monday, February 23, 2015 4:50 PM > > To: Daniel Vetter > > Cc: Barbalho, Rafael; intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context > > destruction > > > > On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote: > > > On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote: > > > > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote: > > > > > Well except that our unbind code is too dense to do that correctly for > > > > > shared buffers, so we need to move obj->active to vma->active first. > > > > > > > > We unbind vma, so what do you mean? > > > > > > The unbind of the vma will block since we track active per-obj instead of > > > per-vma. Which is kinda not that cool for a kref_put cleanup function. > > > > As I have said and shown, that is very easy to rectify and has, for > > example, nice side-effects of basically making operating on fences free > > of blocking on the GPU if the object is busy only in the ppgtt. The > > principle use is so that we are consistent in vma vs obj tracking and > > make the code much cleaner imo. > > My initial implementation was tracking the vma in the request structure but it > wasn't as clean. I'll take everything that has been said on-board and clean > things up, and add an igt test too while I am at it. Conceptually I guess we could split up the active list into something per-request, at least right now. But I think that will totally upset the scheduler work, so just moving obj->active to vmas should be a lot less intrusive indeed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote: > On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote: > > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote: > > > Well except that our unbind code is too dense to do that correctly for > > > shared buffers, so we need to move obj->active to vma->active first. > > > > We unbind vma, so what do you mean? > > The unbind of the vma will block since we track active per-obj instead of > per-vma. Which is kinda not that cool for a kref_put cleanup function. As I have said and shown, that is very easy to rectify and has, for example, nice side-effects of basically making operating on fences free of blocking on the GPU if the object is busy only in the ppgtt. The principle use is so that we are consistent in vma vs obj tracking and make the code much cleaner imo. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, February 23, 2015 4:50 PM > To: Daniel Vetter > Cc: Barbalho, Rafael; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context > destruction > > On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote: > > On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote: > > > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote: > > > > Well except that our unbind code is too dense to do that correctly for > > > > shared buffers, so we need to move obj->active to vma->active first. > > > > > > We unbind vma, so what do you mean? > > > > The unbind of the vma will block since we track active per-obj instead of > > per-vma. Which is kinda not that cool for a kref_put cleanup function. > > As I have said and shown, that is very easy to rectify and has, for > example, nice side-effects of basically making operating on fences free > of blocking on the GPU if the object is busy only in the ppgtt. The > principle use is so that we are consistent in vma vs obj tracking and > make the code much cleaner imo. My initial implementation was tracking the vma in the request structure but it wasn't as clean. I'll take everything that has been said on-board and clean things up, and add an igt test too while I am at it. > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote:
> On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote:
> > On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote:
> > > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> > > > From: Rafael Barbalho
> > > >
> > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to
> > > > be
> > > > cleaned up so that the PPGTT PDE & PTE allocations can be freed.
> > > >
> > > > This problem only shows up with full PPGTT because an object's VMA is
> > > > only cleaned-up when the object is destroyed. However, if the object has
> > > > been shared between multiple processes this may not happen, which leads
> > > > to
> > > > references to the PPGTT still being kept the object was shared.
> > > >
> > > > Under android the sharing of GEM objects is a fairly common operation,
> > > > thus
> > > > the clean-up has to be more agressive.
> > >
> > > Not quite. You need an active refcount as we do not expect close(fd) to
> > > stall. The trick is to "simply" use requests to retire vma (as well as
> > > the object management it does today, though that just becomes a second
> > > layer for GEM API management, everything else goes through vma).
> >
> > Linking into the ctx unref should give us that for free since requests do
> > hold a reference on the context. So this will only be run when the buffers
> > are idle.
> >
> > Well except that our unbind code is too dense to do that correctly for
> > shared buffers, so we need to move obj->active to vma->active first.
>
> We unbind vma, so what do you mean?
The unbind of the vma will block since we track active per-obj instead of
per-vma. Which is kinda not that cool for a kref_put cleanup function.
But yeah the below is what I had in mind too, with the mentioned nuisance
fixed.
-Daniel
>
> This is how I forsee the code:
>
> static int context_idr_cleanup(int id, void *p, void *data)
> {
> struct intel_context *ctx = p;
>
> if (ctx->ppgtt && !i915_gem_context_is_default(ctx)) {
> struct list_head *list;
> struct i915_vma *vma;
>
> /* Decouple the remaining vma to keep the next lookup fast */
> list = &ctx->ppgtt->base.vma_list;
> while (!list_empty(list)) {
> vma = list_first_entry(list, typeof(*vma), vm_link);
> list_del_init(&vma->vm_link);
> list_del_init(&vma->obj_link);
> i915_vma_put(vma);
> }
>
> /* Drop active references to this vm upon retire */
> ctx->ppgtt->base.closed = true;
>
> /* Drop all inactive references (via vma->vm reference) */
> list = &ctx->ppgtt->base.inactive_list;
> while (!list_empty(list)) {
> struct drm_i915_gem_object *obj;
> int ret;
>
> vma = list_first_entry(list, typeof(*vma), mm_list);
> obj = vma->obj;
>
> drm_gem_object_reference(&obj->base);
> ret = i915_vma_unbind(vma);
> drm_gem_object_unreference(&obj->base);
> if (WARN_ON(ret))
> break;
> }
> }
>
> ctx->file_priv = NULL;
> i915_gem_context_unreference(ctx);
>
> return 0;
> }
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Fri, Feb 13, 2015 at 10:05:16AM +, Chris Wilson wrote: > On Fri, Feb 13, 2015 at 10:51:36AM +0100, Daniel Vetter wrote: > > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote: > > > From: Rafael Barbalho > > > > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be > > > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > > > > > This problem only shows up with full PPGTT because an object's VMA is > > > only cleaned-up when the object is destroyed. However, if the object has > > > been shared between multiple processes this may not happen, which leads to > > > references to the PPGTT still being kept the object was shared. > > > > > > Under android the sharing of GEM objects is a fairly common operation, > > > thus > > > the clean-up has to be more agressive. > > > > > > Signed-off-by: Rafael Barbalho > > > Cc: Daniel Vetter > > > Cc: Jon Bloomfield > > > > So when we've merged this we iirc talked about this issue and decided that > > the shrinker should be good enough in cleaning up the crap from shared > > objects. Not a pretty solution, but it should have worked. > > > > Is this again the lowmemory killer wreaking havoc with our i915 shrinker, > > or is there something else going on? And do you have some igt testcase for > > this? If sharing is all that's required the following should do the trick: > > 1. allocate obj > > 2. create new context > > 3. do dummy execbuf with that obj to map it into the ppgtt > > 4. free context > > 5. goto 2 often enough to OOM > > You know I have patches to fix all of this... It just happens to fall > out of tracking vma in requests, and by extension vm. Since you replied to my description of the igt testcase ... What kind of bugs do you mean? I kinda can't find the context here ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote:
> > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> > > From: Rafael Barbalho
> > >
> > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> > > cleaned up so that the PPGTT PDE & PTE allocations can be freed.
> > >
> > > This problem only shows up with full PPGTT because an object's VMA is
> > > only cleaned-up when the object is destroyed. However, if the object has
> > > been shared between multiple processes this may not happen, which leads to
> > > references to the PPGTT still being kept the object was shared.
> > >
> > > Under android the sharing of GEM objects is a fairly common operation,
> > > thus
> > > the clean-up has to be more agressive.
> >
> > Not quite. You need an active refcount as we do not expect close(fd) to
> > stall. The trick is to "simply" use requests to retire vma (as well as
> > the object management it does today, though that just becomes a second
> > layer for GEM API management, everything else goes through vma).
>
> Linking into the ctx unref should give us that for free since requests do
> hold a reference on the context. So this will only be run when the buffers
> are idle.
>
> Well except that our unbind code is too dense to do that correctly for
> shared buffers, so we need to move obj->active to vma->active first.
We unbind vma, so what do you mean?
This is how I forsee the code:
static int context_idr_cleanup(int id, void *p, void *data)
{
struct intel_context *ctx = p;
if (ctx->ppgtt && !i915_gem_context_is_default(ctx)) {
struct list_head *list;
struct i915_vma *vma;
/* Decouple the remaining vma to keep the next lookup fast */
list = &ctx->ppgtt->base.vma_list;
while (!list_empty(list)) {
vma = list_first_entry(list, typeof(*vma), vm_link);
list_del_init(&vma->vm_link);
list_del_init(&vma->obj_link);
i915_vma_put(vma);
}
/* Drop active references to this vm upon retire */
ctx->ppgtt->base.closed = true;
/* Drop all inactive references (via vma->vm reference) */
list = &ctx->ppgtt->base.inactive_list;
while (!list_empty(list)) {
struct drm_i915_gem_object *obj;
int ret;
vma = list_first_entry(list, typeof(*vma), mm_list);
obj = vma->obj;
drm_gem_object_reference(&obj->base);
ret = i915_vma_unbind(vma);
drm_gem_object_unreference(&obj->base);
if (WARN_ON(ret))
break;
}
}
ctx->file_priv = NULL;
i915_gem_context_unreference(ctx);
return 0;
}
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Fri, Feb 13, 2015 at 10:51:36AM +0100, Daniel Vetter wrote: > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote: > > From: Rafael Barbalho > > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be > > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > > > This problem only shows up with full PPGTT because an object's VMA is > > only cleaned-up when the object is destroyed. However, if the object has > > been shared between multiple processes this may not happen, which leads to > > references to the PPGTT still being kept the object was shared. > > > > Under android the sharing of GEM objects is a fairly common operation, thus > > the clean-up has to be more agressive. > > > > Signed-off-by: Rafael Barbalho > > Cc: Daniel Vetter > > Cc: Jon Bloomfield > > So when we've merged this we iirc talked about this issue and decided that > the shrinker should be good enough in cleaning up the crap from shared > objects. Not a pretty solution, but it should have worked. > > Is this again the lowmemory killer wreaking havoc with our i915 shrinker, > or is there something else going on? And do you have some igt testcase for > this? If sharing is all that's required the following should do the trick: > 1. allocate obj > 2. create new context > 3. do dummy execbuf with that obj to map it into the ppgtt > 4. free context > 5. goto 2 often enough to OOM You know I have patches to fix all of this... It just happens to fall out of tracking vma in requests, and by extension vm. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote: > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote: > > From: Rafael Barbalho > > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be > > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > > > This problem only shows up with full PPGTT because an object's VMA is > > only cleaned-up when the object is destroyed. However, if the object has > > been shared between multiple processes this may not happen, which leads to > > references to the PPGTT still being kept the object was shared. > > > > Under android the sharing of GEM objects is a fairly common operation, thus > > the clean-up has to be more agressive. > > Not quite. You need an active refcount as we do not expect close(fd) to > stall. The trick is to "simply" use requests to retire vma (as well as > the object management it does today, though that just becomes a second > layer for GEM API management, everything else goes through vma). Linking into the ctx unref should give us that for free since requests do hold a reference on the context. So this will only be run when the buffers are idle. Well except that our unbind code is too dense to do that correctly for shared buffers, so we need to move obj->active to vma->active first. And yeah the commit message should have explained this. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> cleaned up so that the PPGTT PDE & PTE allocations can be freed.
>
> This problem only shows up with full PPGTT because an object's VMA is
> only cleaned-up when the object is destroyed. However, if the object has
> been shared between multiple processes this may not happen, which leads to
> references to the PPGTT still being kept the object was shared.
>
> Under android the sharing of GEM objects is a fairly common operation, thus
> the clean-up has to be more agressive.
>
> Signed-off-by: Rafael Barbalho
> Cc: Daniel Vetter
> Cc: Jon Bloomfield
So when we've merged this we iirc talked about this issue and decided that
the shrinker should be good enough in cleaning up the crap from shared
objects. Not a pretty solution, but it should have worked.
Is this again the lowmemory killer wreaking havoc with our i915 shrinker,
or is there something else going on? And do you have some igt testcase for
this? If sharing is all that's required the following should do the trick:
1. allocate obj
2. create new context
3. do dummy execbuf with that obj to map it into the ppgtt
4. free context
5. goto 2 often enough to OOM
The shrinker should eventually kick in and clean up, but maybe I'm wrong
about that ...
One thing I've thought of is that if the shared object is pinned as a
scanout buffer then the shrinker won't touch it. But not sure whether you
can actually do this to end up with a stable leak - after each pageflip
the shrinker evict the vma/obj for this eventually.
> ---
> drivers/gpu/drm/i915/i915_gem.c | 7 +++---
> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 43
> -
> drivers/gpu/drm/i915/i915_gem_gtt.h | 7 ++
> 4 files changed, 54 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 60b8bd1..e509d89 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4529,11 +4529,12 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
> return;
>
> vm = vma->vm;
> + list_del(&vma->vma_link);
>
> - if (!i915_is_ggtt(vm))
> + if (!i915_is_ggtt(vm)) {
> + list_del(&vma->vm_link);
> i915_ppgtt_put(i915_vm_to_ppgtt(vm));
> -
> - 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 a5221d8..4319a93 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -140,7 +140,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
> if (i915.enable_execlists)
> intel_lr_context_free(ctx);
>
> - i915_ppgtt_put(ctx->ppgtt);
> + i915_ppgtt_destroy(ctx->ppgtt);
>
> if (ctx->legacy_hw_ctx.rcs_state)
> drm_gem_object_unreference(&ctx->legacy_hw_ctx.rcs_state->base);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 6f410cf..9ef2f67 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1097,6 +1097,7 @@ static int __hw_ppgtt_init(struct drm_device *dev,
> struct i915_hw_ppgtt *ppgtt)
> else
> BUG();
> }
> +
> int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1108,6 +1109,8 @@ int i915_ppgtt_init(struct drm_device *dev, struct
> i915_hw_ppgtt *ppgtt)
> drm_mm_init(&ppgtt->base.mm, ppgtt->base.start,
> ppgtt->base.total);
> i915_init_vm(dev_priv, &ppgtt->base);
> +
> + INIT_LIST_HEAD(&ppgtt->vma_list);
> }
>
> return ret;
> @@ -1177,14 +1180,49 @@ void i915_ppgtt_release(struct kref *kref)
> /* vmas should already be unbound */
> WARN_ON(!list_empty(&ppgtt->base.active_list));
> WARN_ON(!list_empty(&ppgtt->base.inactive_list));
> + WARN_ON(!list_empty(&ppgtt->vma_list));
>
> list_del(&ppgtt->base.global_link);
> drm_mm_takedown(&ppgtt->base.mm);
>
> ppgtt->base.cleanup(&ppgtt->base);
> +
> kfree(ppgtt);
> }
>
> +void
> +i915_ppgtt_destroy(struct i915_hw_ppgtt *ppgtt)
This is misnamed since what it really does is unbind everything and then
drop the reference. Unbinding everything is already implemented as
i915_gem_evict_vm.
Also unconditionally evicting the entire vm upon context destruction means
we essentially assume a 1:1 link between ctx and ppgtt. Which is currently
true but will change with the interfaces planned for buffered svm.
I think we need a new ctx_use_count besides the pointer refcount that we
inc/dec on context d
Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote: > From: Rafael Barbalho > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > This problem only shows up with full PPGTT because an object's VMA is > only cleaned-up when the object is destroyed. However, if the object has > been shared between multiple processes this may not happen, which leads to > references to the PPGTT still being kept the object was shared. > > Under android the sharing of GEM objects is a fairly common operation, thus > the clean-up has to be more agressive. Not quite. You need an active refcount as we do not expect close(fd) to stall. The trick is to "simply" use requests to retire vma (as well as the object management it does today, though that just becomes a second layer for GEM API management, everything else goes through vma). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
From: Rafael Barbalho
With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
cleaned up so that the PPGTT PDE & PTE allocations can be freed.
This problem only shows up with full PPGTT because an object's VMA is
only cleaned-up when the object is destroyed. However, if the object has
been shared between multiple processes this may not happen, which leads to
references to the PPGTT still being kept the object was shared.
Under android the sharing of GEM objects is a fairly common operation, thus
the clean-up has to be more agressive.
Signed-off-by: Rafael Barbalho
Cc: Daniel Vetter
Cc: Jon Bloomfield
---
drivers/gpu/drm/i915/i915_gem.c | 7 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 43 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 ++
4 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 60b8bd1..e509d89 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4529,11 +4529,12 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
return;
vm = vma->vm;
+ list_del(&vma->vma_link);
- if (!i915_is_ggtt(vm))
+ if (!i915_is_ggtt(vm)) {
+ list_del(&vma->vm_link);
i915_ppgtt_put(i915_vm_to_ppgtt(vm));
-
- 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 a5221d8..4319a93 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -140,7 +140,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
if (i915.enable_execlists)
intel_lr_context_free(ctx);
- i915_ppgtt_put(ctx->ppgtt);
+ i915_ppgtt_destroy(ctx->ppgtt);
if (ctx->legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(&ctx->legacy_hw_ctx.rcs_state->base);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6f410cf..9ef2f67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1097,6 +1097,7 @@ static int __hw_ppgtt_init(struct drm_device *dev, struct
i915_hw_ppgtt *ppgtt)
else
BUG();
}
+
int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1108,6 +1109,8 @@ int i915_ppgtt_init(struct drm_device *dev, struct
i915_hw_ppgtt *ppgtt)
drm_mm_init(&ppgtt->base.mm, ppgtt->base.start,
ppgtt->base.total);
i915_init_vm(dev_priv, &ppgtt->base);
+
+ INIT_LIST_HEAD(&ppgtt->vma_list);
}
return ret;
@@ -1177,14 +1180,49 @@ void i915_ppgtt_release(struct kref *kref)
/* vmas should already be unbound */
WARN_ON(!list_empty(&ppgtt->base.active_list));
WARN_ON(!list_empty(&ppgtt->base.inactive_list));
+ WARN_ON(!list_empty(&ppgtt->vma_list));
list_del(&ppgtt->base.global_link);
drm_mm_takedown(&ppgtt->base.mm);
ppgtt->base.cleanup(&ppgtt->base);
+
kfree(ppgtt);
}
+void
+i915_ppgtt_destroy(struct i915_hw_ppgtt *ppgtt)
+{
+ struct i915_vma *vma, *tmp;
+ struct i915_address_space *vm;
+ int ret;
+
+ if (!ppgtt)
+ return;
+
+ vm = &ppgtt->base;
+
+ /*
+* If this fires it means that the context reference counting went
+* awry.
+*/
+ WARN_ON(!list_empty(&ppgtt->base.active_list));
+
+ if (!list_empty(&ppgtt->vma_list))
+ list_for_each_entry_safe(vma, tmp, &ppgtt->vma_list, vm_link) {
+ WARN_ON(vma->pin_count != 0);
+ /*
+* The object should be inactive at this point, thus
+* its pin_count should be 0. We will zero it anyway
+* make sure that the unbind call succeeds.
+*/
+ vma->pin_count = 0;
+ ret = i915_vma_unbind(vma);
+ }
+
+ i915_ppgtt_put(ppgtt);
+}
+
static void
ppgtt_bind_vma(struct i915_vma *vma,
enum i915_cache_level cache_level,
@@ -2109,6 +2147,7 @@ static struct i915_vma *__i915_gem_vma_create(struct
drm_i915_gem_object *obj,
return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&vma->vma_link);
+ INIT_LIST_HEAD(&vma->vm_link);
INIT_LIST_HEAD(&vma->mm_list);
INIT_LIST_HEAD(&vma->exec_list);
vma->vm = vm;
@@ -2142,8 +2181,10 @@ static struct i915_vma *__i915_gem_vma_create(struct
drm_i915_gem_object *obj,
if (i915_is_ggtt(vm))
list_add(&vma->vma_link, &obj->vma_list);
else {
+ struct i915
