[Intel-gfx] [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects

[Chris Wilson]

On Mon, Apr 20, 2015 at 02:11:39PM +0100, Tvrtko Ursulin wrote:
> 
> On 04/20/2015 01:58 PM, Chris Wilson wrote:
> >On Mon, Apr 20, 2015 at 01:53:03PM +0100, Tvrtko Ursulin wrote:
> >>>No we can't do this, as it makes close sync and so can have disasterous
> >>>effects on performance (though mitigated chiefly by userspace
> >>>agressively caching bo) and also the unbind is very likely to fail,
> >>>though admittedly the fbcon copy should be before X starts (ab)using
> >>>signals - hence nasty WARN_ON.
> >>>
> >>>Plus also walking this linear list is quite painful in certain abusive
> >>>tests. My preference for fixing this bug would be via vma active
> >>>references and auto-unbinding on retirement after a close.
> >>
> >>Why this is any different today with GEM_CLOSE having pretty similar
> >>VMA unbind loop? Is the typical (and interesting) case not that
> >>GEM_CLOSE will trigger gem_object_close and gem_object_free at the
> >>same invocation?
> >
> >We have such a cleanup loop in free_object, but we have an active
> >reference to ensure that we only do so once the object is idle (and
> >unbinding won't cause to wait).
> 
> Is that a predominant situation - closing of active objects vs
> inactive? It would be surprising (to me).

Relatively rare due to our aggressive userspace caching. (You can look
at a couple of other drivers which don't use either such an aggressive
cache or employ active references to see how much it hurts *cough*
nouveau *cough*). However, we do hit it often enough through flinked
buffers which can't be safely reused and so get closed as soon as we
finish referencing them in commands.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre