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

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

[Chris Wilson]

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@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 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)
-- 
2.17.0

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

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

[Chris Wilson]

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@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 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)
-- 
2.17.0

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for igt/drv_missed_irq: Sleep in the child waiting for the parent

[Patchwork]

== Series Details ==

Series: igt/drv_missed_irq: Sleep in the child waiting for the parent
URL   : https://patchwork.freedesktop.org/series/42512/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4116 -> IGTPW_1310 =

== Summary - WARNING ==

  Minor unknown changes coming with IGTPW_1310 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_1310, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/42512/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in IGTPW_1310:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_gttfill@basic:
      fi-pnv-d510:        PASS -> SKIP

    
== Known issues ==

  Here are the changes found in IGTPW_1310 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_mmap_gtt@basic-small-bo-tiledx:
      fi-gdg-551:         PASS -> FAIL (fdo#102575)

    
    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-ivb-3520m:       DMESG-WARN (fdo#106084) -> PASS
      fi-bxt-dsi:         INCOMPLETE (fdo#103927) -> PASS

    
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (38 -> 35) ==

  Missing    (3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

    * IGT: IGT_4453 -> IGTPW_1310

  CI_DRM_4116: 7ff375cb94000d93f7a9d541cb0c8180fbea80f2 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1310: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1310/
  IGT_4453: 29ae12bd764e3b1876356e7628a32192b4ec9066 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4453: d0a0bca2194a673c4d9a70a2256837c59213c64b @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1310/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for igt/drv_missed_irq: Sleep in the child waiting for the parent

[Patchwork]

== Series Details ==

Series: igt/drv_missed_irq: Sleep in the child waiting for the parent
URL   : https://patchwork.freedesktop.org/series/42512/
State : success

== Summary ==

= CI Bug Log - changes from IGT_4453_full -> IGTPW_1310_full =

== Summary - WARNING ==

  Minor unknown changes coming with IGTPW_1310_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_1310_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/42512/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in IGTPW_1310_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_mocs_settings@mocs-rc6-bsd1:
      shard-kbl:          SKIP -> PASS +2

    igt@gem_mocs_settings@mocs-rc6-vebox:
      shard-kbl:          PASS -> SKIP +1

    igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip:
      shard-snb:          PASS -> SKIP

    
== Known issues ==

  Here are the changes found in IGTPW_1310_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_mmap_gtt@coherency:
      shard-glk:          NOTRUN -> FAIL (fdo#100587)

    igt@kms_flip@modeset-vs-vblank-race:
      shard-hsw:          PASS -> FAIL (fdo#103060)

    igt@kms_flip@plain-flip-ts-check:
      shard-hsw:          PASS -> FAIL (fdo#100368) +1

    igt@kms_flip@plain-flip-ts-check-interruptible:
      shard-glk:          PASS -> FAIL (fdo#100368)

    igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack:
      shard-kbl:          PASS -> DMESG-WARN (fdo#103558, fdo#105602) +11

    igt@perf_pmu@busy-accuracy-50-rcs0:
      shard-glk:          PASS -> FAIL (fdo#105157)

    
    ==== Possible fixes ====

    igt@drv_selftest@live_gtt:
      shard-apl:          INCOMPLETE (fdo#103927) -> PASS

    igt@gem_workarounds@suspend-resume:
      shard-kbl:          INCOMPLETE (fdo#103665) -> PASS

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
      shard-apl:          FAIL (fdo#103207) -> PASS

    igt@kms_cursor_crc@cursor-128x128-suspend:
      shard-glk:          INCOMPLETE -> PASS

    igt@kms_flip@2x-plain-flip-fb-recreate:
      shard-hsw:          FAIL (fdo#100368) -> PASS

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-glk:          FAIL (fdo#102887) -> PASS

    igt@kms_flip@plain-flip-ts-check:
      shard-kbl:          DMESG-WARN (fdo#103558, fdo#105602) -> PASS +23

    igt@kms_flip@wf_vblank-ts-check-interruptible:
      shard-glk:          FAIL (fdo#100368) -> PASS +2

    igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
      shard-kbl:          DMESG-WARN (fdo#103558, fdo#103313, fdo#105602) -> PASS +5

    igt@pm_rpm@fences:
      shard-kbl:          DMESG-WARN (fdo#103313) -> PASS +1

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105157 https://bugs.freedesktop.org/show_bug.cgi?id=105157
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602


== Participating hosts (8 -> 5) ==

  Missing    (3): pig-skl-6600 pig-glk-j4005 pig-hsw-4770r 


== Build changes ==

    * IGT: IGT_4453 -> IGTPW_1310
    * Linux: CI_DRM_4113 -> CI_DRM_4116

  CI_DRM_4113: 1d2a421b1f9b47883b9d0eeb28dc4069e462dbe3 @ git://anongit.freedesktop.org/gfx-ci/linux
  CI_DRM_4116: 7ff375cb94000d93f7a9d541cb0c8180fbea80f2 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1310: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1310/
  IGT_4453: 29ae12bd764e3b1876356e7628a32192b4ec9066 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4453: d0a0bca2194a673c4d9a70a2256837c59213c64b @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1310/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

[Tvrtko Ursulin]

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@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tvrtko Ursulin]

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@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   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
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-01 12:10:22)
> 
> 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@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   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?

No, we need to wait inside the gem_sync in order to turn on the irq. We
do need to get passed that first busy-spin loop. The fun part about this
setup was that it didn't require any more knowledge than knowing when it
scheduled it was waiting on the interrupt; and thus we didn't need
arbitrary timeouts and could be quite rapid.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-01 12:10:22)
> 
> 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@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   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?

No, we need to wait inside the gem_sync in order to turn on the irq. We
do need to get passed that first busy-spin loop. The fun part about this
setup was that it didn't require any more knowledge than knowing when it
scheduled it was waiting on the interrupt; and thus we didn't need
arbitrary timeouts and could be quite rapid.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

[Tvrtko Ursulin]

On 01/05/2018 12:21, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-05-01 12:10:22)
>>
>> 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@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>>    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?
> 
> No, we need to wait inside the gem_sync in order to turn on the irq. We
> do need to get passed that first busy-spin loop. The fun part about this
> setup was that it didn't require any more knowledge than knowing when it
> scheduled it was waiting on the interrupt; and thus we didn't need
> arbitrary timeouts and could be quite rapid.

I was thinking, as much as the pipe comms improve the odds child will 
not terminate the spin until the parent is in wait, if we could get rid 
of the RT requirement by being even more explicit in synchronization.

But true, it would need a timed wait, so a slightly slower test, after 
which parent would signal the child to terminate.

Anyway, don't see any issues with this version:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

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

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

[Tvrtko Ursulin]

On 01/05/2018 12:21, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-05-01 12:10:22)
>>
>> 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@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>>    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?
> 
> No, we need to wait inside the gem_sync in order to turn on the irq. We
> do need to get passed that first busy-spin loop. The fun part about this
> setup was that it didn't require any more knowledge than knowing when it
> scheduled it was waiting on the interrupt; and thus we didn't need
> arbitrary timeouts and could be quite rapid.

I was thinking, as much as the pipe comms improve the odds child will 
not terminate the spin until the parent is in wait, if we could get rid 
of the RT requirement by being even more explicit in synchronization.

But true, it would need a timed wait, so a slightly slower test, after 
which parent would signal the child to terminate.

Anyway, don't see any issues with this version:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev