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).
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
