All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Rafael Barbalho <rafael.barbalho@intel.com>,
	Michel Thierry <michel.thierry@intel.com>
Subject: Re: [PATCH] drm/i915: Clean up associated VMAs on context destruction
Date: Fri, 11 Sep 2015 16:18:06 +0100	[thread overview]
Message-ID: <55F2F0AE.8080505@linux.intel.com> (raw)
In-Reply-To: <20150911145653.GW32324@nuc-i3427.alporthouse.com>


On 09/11/2015 03:56 PM, Chris Wilson wrote:
> On Fri, Sep 11, 2015 at 03:31:33PM +0100, 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
>> destruction) and tries to incorporate the subsequent discussion
>> between Chris Wilson and Daniel Vetter.
>>
>> On context destruction a VM is marked as closed and a worker
>> thread scheduled to unbind all inactive VMAs for this VM. At
>> the same time, active VMAs retired on this closed VM are
>> unbound immediately.
>
> You don't need a worker, since you just can just drop the vma from the
> retirement.

I was thinking that retirement does not necessarily happen - maybe both 
VMAs are already inactive at the time of context destruction. Which is 
then a question is it OK to wait for the next retirement on the same 
object to clean it up. I wasn't sure so thought it is safer to clean it 
up immediately since it is not a lot of code.

> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=9d4020dce054cca23bd1fea72092d036f0a3ea13
>
> That patch is as old as the test case, just waiting for some review on
> earlier code.

Plus my patch doesn't fix flink-and-close-vma-leak, but a new one I also 
posted, flink-and-exit-vma-leak. The latter is what was affecting 
Android, and can be seen with X.org and fbcon.

Your cleanup and handle close is more complete but a question is how 
long will "just waiting for some review on earlier code" take :), 
especially considering it depends on a bigger rewrite of the core.

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-09-11 15:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 14:31 [PATCH] drm/i915: Clean up associated VMAs on context destruction Tvrtko Ursulin
2015-09-11 14:56 ` Chris Wilson
2015-09-11 15:18   ` Tvrtko Ursulin [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=55F2F0AE.8080505@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=michel.thierry@intel.com \
    --cc=rafael.barbalho@intel.com \
    --cc=tvrtko.ursulin@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.