[PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Chris Wilson]

Part of the attraction of using a recursive batch is that it is
hard on the system (executing the "function" call is apparently
quite expensive). However, the GPU may hog the entire system for
a few minutes, preventing even NMI. Quite why this is so is unclear,
but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
If we give the system a break by having the GPU execute a few nops
between function calls, that appears enough to keep SNB out of
trouble.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 lib/igt_dummyload.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 00c6a030..c6e57cff 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -103,7 +103,7 @@ static void emit_recursive_batch(igt_spin_t *spin,
 		/* dummy write to dependency */
 		obj[SCRATCH].handle = dep;
 		fill_reloc(&relocs[obj[BATCH].relocation_count++],
-			   dep, 256,
+			   dep, 1020,
 			   I915_GEM_DOMAIN_RENDER,
 			   I915_GEM_DOMAIN_RENDER);
 		execbuf.buffer_count++;
@@ -112,9 +112,23 @@ static void emit_recursive_batch(igt_spin_t *spin,
 	spin->batch = batch;
 	spin->handle = obj[BATCH].handle;
 
+	/* Pad with a few nops so that we do not completely hog the system.
+	 *
+	 * Part of the attraction of using a recursive batch is that it is
+	 * hard on the system (executing the "function" call is apparently
+	 * quite expensive). However, the GPU may hog the entire system for
+	 * a few minutes, preventing even NMI. Quite why this is so is unclear,
+	 * but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
+	 * If we give the system a break by having the GPU execute a few nops
+	 * between function calls, that appears enough to keep SNB out of
+	 * trouble. See https://
+	 */
+	batch += 1000;
+
 	/* recurse */
 	fill_reloc(&relocs[obj[BATCH].relocation_count],
-		   obj[BATCH].handle, 1, I915_GEM_DOMAIN_COMMAND, 0);
+		   obj[BATCH].handle, (batch - spin->batch) + 1,
+		   I915_GEM_DOMAIN_COMMAND, 0);
 	if (gen >= 8) {
 		*batch++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
 		*batch++ = 0;
-- 
2.14.1

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

✓ Fi.CI.BAT: success for lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Patchwork]

== Series Details ==

Series: lib/dummyload: Pad with a few nops so that we do not completely hog the system
URL   : https://patchwork.freedesktop.org/series/28871/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
c8811338e8a7723b5e99a303361ed97c092fc270 intel-ci: Add fast-feedback-simulation.testlist

with latest DRM-Tip kernel build CI_DRM_2968
5118c7fa9c87 drm-tip: 2017y-08m-15d-23h-58m-24s UTC integration manifest

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                pass       -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:455s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:437s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:364s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:553s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:529s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:523s
fi-byt-n2820     total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  time:516s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:606s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:447s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:424s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:434s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:500s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:477s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:477s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:596s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:597s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:532s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:472s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:478s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:490s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:445s
fi-skl-x1585l    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:502s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:541s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:410s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_70/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Jani Nikula]

On Wed, 16 Aug 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> +	 * trouble. See https://

Oops?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Chris Wilson]

Quoting Jani Nikula (2017-08-16 15:08:47)
> On Wed, 16 Aug 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > +      * trouble. See https://
> 
> Oops?

It was a fill in the blank. I don't think we have a bug report for this
yet.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Mika Kuoppala]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Part of the attraction of using a recursive batch is that it is
> hard on the system (executing the "function" call is apparently
> quite expensive). However, the GPU may hog the entire system for
> a few minutes, preventing even NMI. Quite why this is so is unclear,
> but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
> If we give the system a break by having the GPU execute a few nops
> between function calls, that appears enough to keep SNB out of
> trouble.
>

Can we trip into the same pit with igt_hang? It has tight
recurse. Adding few noops makes the hangcheck sampler
to hit more sparsely and slow the verdict of hang.

But we can then improve the heuristics ;)

-Mika



> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  lib/igt_dummyload.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index 00c6a030..c6e57cff 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -103,7 +103,7 @@ static void emit_recursive_batch(igt_spin_t *spin,
>  		/* dummy write to dependency */
>  		obj[SCRATCH].handle = dep;
>  		fill_reloc(&relocs[obj[BATCH].relocation_count++],
> -			   dep, 256,
> +			   dep, 1020,
>  			   I915_GEM_DOMAIN_RENDER,
>  			   I915_GEM_DOMAIN_RENDER);
>  		execbuf.buffer_count++;
> @@ -112,9 +112,23 @@ static void emit_recursive_batch(igt_spin_t *spin,
>  	spin->batch = batch;
>  	spin->handle = obj[BATCH].handle;
>  
> +	/* Pad with a few nops so that we do not completely hog the system.
> +	 *
> +	 * Part of the attraction of using a recursive batch is that it is
> +	 * hard on the system (executing the "function" call is apparently
> +	 * quite expensive). However, the GPU may hog the entire system for
> +	 * a few minutes, preventing even NMI. Quite why this is so is unclear,
> +	 * but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
> +	 * If we give the system a break by having the GPU execute a few nops
> +	 * between function calls, that appears enough to keep SNB out of
> +	 * trouble. See https://
> +	 */
> +	batch += 1000;
> +
>  	/* recurse */
>  	fill_reloc(&relocs[obj[BATCH].relocation_count],
> -		   obj[BATCH].handle, 1, I915_GEM_DOMAIN_COMMAND, 0);
> +		   obj[BATCH].handle, (batch - spin->batch) + 1,
> +		   I915_GEM_DOMAIN_COMMAND, 0);
>  	if (gen >= 8) {
>  		*batch++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
>  		*batch++ = 0;
> -- 
> 2.14.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] lib/dummyload: Pad with a few nops so that we do not completely hog the system

[Chris Wilson]

Quoting Mika Kuoppala (2017-08-16 15:45:54)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > Part of the attraction of using a recursive batch is that it is
> > hard on the system (executing the "function" call is apparently
> > quite expensive). However, the GPU may hog the entire system for
> > a few minutes, preventing even NMI. Quite why this is so is unclear,
> > but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
> > If we give the system a break by having the GPU execute a few nops
> > between function calls, that appears enough to keep SNB out of
> > trouble.
> >
> 
> Can we trip into the same pit with igt_hang? It has tight
> recurse. Adding few noops makes the hangcheck sampler
> to hit more sparsely and slow the verdict of hang.

And a few others. The reason we stuck the invalid op in there in the
first place was because we didn't have the PM_INTRMSK w/a in place and
we could take out the system. It's that I fear is going wrong, but we
always call gen6_sanitize_rps_pm_mask() now. Ville says that
I915_WRITE(GEN6_RP_CONTROL, 0) is just as fatal. So we may have to
rethink gen6_disable_rps().
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx