From: Michel Thierry <michel.thierry@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
"Intel-gfx@lists.freedesktop.org"
<Intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v3] drm/i915: Clean up associated VMAs on context destruction
Date: Mon, 5 Oct 2015 12:21:05 +0100 [thread overview]
Message-ID: <56125D21.7030901@intel.com> (raw)
In-Reply-To: <1442927760-21865-1-git-send-email-tvrtko.ursulin@linux.intel.com>
On 9/22/2015 2:16 PM, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Prevent leaking VMAs and PPGTT VMs when objects are imported
> via flink.
>
> Scenario is that any VMAs created by the importer will be left
> dangling after the importer exits, or destroys the PPGTT context
> with which they are associated.
>
> This is caused by object destruction not running when the
> importer closes the buffer object handle due the reference held
> by the exporter. This also leaks the VM since the VMA has a
> reference on it.
>
> In practice these leaks can be observed by stopping and starting
> the X server on a kernel with fbcon compiled in. Every time
> X server exits another VMA will be leaked against the fbcon's
> frame buffer object.
>
> Also on systems where flink buffer sharing is used extensively,
> like Android, this leak has even more serious consequences.
>
> This version is takes a general approach from the earlier work
> by Rafael Barabalho (drm/i915: Clean-up PPGTT on context
^Barbalho
> destruction) and tries to incorporate the subsequent discussion
> between Chris Wilson and Daniel Vetter.
>
> v2:
>
> Removed immediate cleanup on object retire - it was causing a
> recursive VMA unbind via i915_gem_object_wait_rendering. And
> it is in fact not even needed since by definition context
> cleanup worker runs only after the last context reference has
> been dropped, hence all VMAs against the VM belonging to the
> context are already on the inactive list.
>
> v3:
>
> Previous version could deadlock since VMA unbind waits on any
> rendering on an object to complete. Objects can be busy in a
> different VM which would mean that the cleanup loop would do
> the wait with the struct mutex held.
>
> This is an even simpler approach where we just unbind VMAs
> without waiting since we know all VMAs belonging to this VM
> are idle, and there is nothing in flight, at the point
> context destructor runs.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
I guess we'll have to wait a bit more to have a fix for
flink-and-close-vma-leak subtest... Anyway, this addresses the flink
leak (also seen in bug 87729 - igt/gem_close_race)
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rafael Barbalho <rafael.barbalho@intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +++++
> drivers/gpu/drm/i915/i915_gem.c | 20 ++++++++++++++++----
> drivers/gpu/drm/i915/i915_gem_context.c | 24 ++++++++++++++++++++++++
> 3 files changed, 45 insertions(+), 4 deletions(-)
>
> @@ -3274,6 +3276,16 @@ int i915_vma_unbind(struct i915_vma *vma)
> return 0;
> }
>
> +int i915_vma_unbind(struct i915_vma *vma)
> +{
> + return __i915_vma_unbind(vma, true);
> +}
> +
> +int _i915_vma_unbind_no_wait(struct i915_vma *vma)
^ it needs one more underscore (__i915_vma_unbind_no_wait).
> +{
> + return __i915_vma_unbind(vma, false);
> +}
> +
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2015-10-05 11:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 13:16 [PATCH v3] drm/i915: Clean up associated VMAs on context destruction Tvrtko Ursulin
2015-10-05 11:21 ` Michel Thierry [this message]
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=56125D21.7030901@intel.com \
--to=michel.thierry@intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=tvrtko.ursulin@linux.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.