Re: i-g-t prime_self_import & gem_flink_race: leaked -1 objects

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Nov 01, 2013 at 12:55:54PM +0000, Mateo Lozano, Oscar wrote:
> Hi Ben,
> 
> I´ll switch the conversation to the mailing list...
> 
> In the case of prime_self_import, the problem is self-contained (it
> doesn´t really need a previous test A): the first subtest opens the
> first fd, which provokes a context switch (gem_quiescent_gpu). This
> switch is actually completed (gem_quiescent_gpu makes sure with a
> gem_sync) and the old context disposed of, but its backing object
> remains alive until a retire_work kicks in (which in my case usually
> happens in the middle of the prime_self_test/export-vs-gem_close-race
> subtest, thus the "-1 objects leaked"). The comment in do_switch says it
> all:
> 
> 	/* The backing object for the context is done after switching to the
> 	 * *next* context. Therefore we cannot retire the previous context until
> 	 * the next context has already started running. In fact, the below code
> 	 * is a bit suboptimal because the retiring can occur simply after the
> 	 * MI_SET_CONTEXT instead of when the next seqno has completed.
> 	 */
> 
> I´ll send a fix for prime_self_import, but... maybe we should make sure
> that the GPU is really quiescent, rather than fixing individual tests?
> (retire requests via drop caches at the end of gem_quiescent_gpu?).

Cool, you've already thought of my suggestion for your patch. Please
implement, I like it ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch