Re: [PATCH i-g-t 2/3] tests/perf_pmu: Simplify interrupt testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 20/12/2017 10:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-12-20 09:45:41)

On 19/12/2017 21:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-12-19 15:45:42)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

Rather than calibrate and emit nop batches, use a manually signalled chain
of spinners to generate the desired interrupts.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
-       /* Unplug the calibrated queue and wait for all the fences */
-       igt_spin_batch_free(gem_fd, spin);
-       igt_assert_eq(poll(&pfd, 1, 2 * test_duration_ms), 1);
-       close(pfd.fd);
+               pfd.fd = spin[i]->out_fence;
+               igt_spin_batch_set_timeout(spin[i], timeout_ms * 1e6);
+               igt_assert_eq(poll(&pfd, 1, 2 * timeout_ms), 1);

Oh, still with the synchronous behaviour, bleurgh.

I was attracted by the simplicity of this approach, but I can change to
set incremental timeouts and keep the merged fence if you think that's
better?

It was mostly surprise as I just have a preference for setting up
everything and then letting it go; fire-and-forget style. So that was
what I was expecting to see. It should basically be the difference of
adding a single function to merge the fences (albeit you have to write
that function). Shall we say both patterns have merit / analogues to the
real world?

It is using fence merging approach so it won't be a problem to keep that, just with the spin batches. I mostly wanted to remove calibration since you were nudging me in that direction. Don't mind really of the specific mechanics of emitting interrupts so I am happy to go back a step.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux