Re: [PATCH i-g-t] igt/drv_missed_irq: Sleep in the child waiting for the parent

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

 




On 01/05/2018 10:07, Chris Wilson wrote:
Our parent is RT, we are not. In theory, we should wait until our parent
has gone to sleep before we are allowed to proceed (we should both be
bound to the same cpu). Double down on this by sleeping in the child
until our parent has written a byte along a pipe().

Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
  tests/drv_missed_irq.c | 11 ++++++++++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tests/drv_missed_irq.c b/tests/drv_missed_irq.c
index 9326a5a62..791ee51fb 100644
--- a/tests/drv_missed_irq.c
+++ b/tests/drv_missed_irq.c
@@ -34,20 +34,29 @@ IGT_TEST_DESCRIPTION("Inject missed interrupts and make sure they are caught");
  static void trigger_missed_interrupt(int fd, unsigned ring)
  {
  	igt_spin_t *spin = __igt_spin_batch_new(fd, 0, ring, 0);
+	uint32_t go;
+	int link[2];
+
+	igt_assert(pipe(link) == 0);
igt_fork(child, 1) {
-		/* We are now a low priority child on the *same* CPU as the
+		/*
+		 * We are now a low priority child on the *same* CPU as the
  		 * parent. We will have to wait for our parent to sleep
  		 * (gem_sync -> i915_wait_request) before we run.
  		 */
+		read(link[0], &go, sizeof(go));
  		igt_assert(gem_bo_busy(fd, spin->handle));
  		igt_spin_batch_end(spin);
  	}
+ write(link[1], &go, sizeof(go));
  	gem_sync(fd, spin->handle);
  	igt_waitchildren();
igt_spin_batch_free(fd, spin);
+	close(link[1]);
+	close(link[0]);
  }
static void bind_to_cpu(int cpu)


Does the parent need to be RT at all now? Would it work to use a short(er) timed wait and signal back to the child to terminate the spinner only then? Fake missing interrupt only needs some wait, right?

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