[Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction
Daniel Vetter
daniel at ffwll.ch
Fri Feb 13 01:51:36 PST 2015
On Thu, Feb 12, 2015 at 08:05:02PM +0000, rafael.barbalho at intel.com wrote:
> From: Rafael Barbalho <rafael.barbalho at intel.com>
>
> 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 <rafael.barbalho at intel.com>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Jon Bloomfield <jon.bloomfield at intel.com>
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 desctruction. And then we only call evict_vm when that
drops to 0.
> +{
> + 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);
Imo this should be moved back into the ctx destruction code, hiding it
liek this makes auditing the refcounting a lot harder. Especially if the
wrapping function doesn't use the magic get/put words used for
refcounting.
Cheers, Daniel
> +}
> +
> 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);
We have that already, right below ;-)
Cheers, Daniel
> 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_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
> list_add_tail(&vma->vma_link, &obj->vma_list);
> - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> + i915_ppgtt_get(ppgtt);
> + list_add_tail(&vma->vm_link, &ppgtt->vma_list);
> }
>
> return vma;
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index d5c14af..323bbc6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -128,6 +128,8 @@ struct i915_vma {
>
> struct list_head vma_link; /* Link in the object's VMA list */
>
> + struct list_head vm_link; /* Link in the VM's VMA list */
> +
> /** This vma's place in the batchbuffer or on the eviction list */
> struct list_head exec_list;
>
> @@ -149,6 +151,7 @@ struct i915_vma {
> * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
> * bits with absolutely no headroom. So use 4 bits. */
> unsigned int pin_count:4;
> +
> #define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
>
> /** Unmap an object from an address space. This usually consists of
> @@ -262,6 +265,8 @@ struct i915_hw_ppgtt {
>
> struct drm_i915_file_private *file_priv;
>
> + struct list_head vma_list;
> +
> int (*enable)(struct i915_hw_ppgtt *ppgtt);
> int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
> struct intel_engine_cs *ring);
> @@ -280,6 +285,8 @@ int i915_ppgtt_init_hw(struct drm_device *dev);
> void i915_ppgtt_release(struct kref *kref);
> struct i915_hw_ppgtt *i915_ppgtt_create(struct drm_device *dev,
> struct drm_i915_file_private *fpriv);
> +void i915_ppgtt_destroy(struct i915_hw_ppgtt *ppgtt);
> +
> static inline void i915_ppgtt_get(struct i915_hw_ppgtt *ppgtt)
> {
> if (ppgtt)
> --
> 2.3.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list