Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

2018-05-14 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-05-14 12:03:58) > > On 14/05/2018 09:02, Chris Wilson wrote: > > trigger_reset() imposes a tight time constraint (2s) so that we verify > > that the reset itself completes quickly. In the middle of this check, we > > call gem_quiescent_gpu() which may invoke an

Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

2018-05-14 Thread Tvrtko Ursulin
On 14/05/2018 09:02, Chris Wilson wrote: trigger_reset() imposes a tight time constraint (2s) so that we verify that the reset itself completes quickly. In the middle of this check, we call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to clear out the freed memory (DROP_FREED).

[Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

2018-05-14 Thread Chris Wilson
trigger_reset() imposes a tight time constraint (2s) so that we verify that the reset itself completes quickly. In the middle of this check, we call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to clear out the freed memory (DROP_FREED). Those barriers may have unbounded latency