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