Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Chris Wilson]

Quoting Caz Yokoyama (2019-03-06 00:06:55)
> Less iterate because WAIT_EXTRA adds extra 5 sec delay for each iteration.
> This test is similar to gem-execbuf-stress except for WAIT_EXTRA.
> It runs 86 sec. while gem-execbuf-stress runs 38 sec.
> i.e. 38s + iteration(rounds,10) * 5s = 88s

Why does it wait for 5s? There's no second stage to runtime suspend, but
if there was, add a debug interface to force it.

Something else that can be employed to speed up this test would be
igt_drop_caches_set(DROP_IDLE) (before waiting for runtime suspend).
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Patchwork]

== Series Details ==

Series: series starting with [i-g-t,1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster
URL   : https://patchwork.freedesktop.org/series/57592/
State : success

== Summary ==

CI Bug Log - changes from IGT_4871 -> IGTPW_2556
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_basic@readonly-bsd2:
    - fi-pnv-d510:        NOTRUN -> SKIP [fdo#109271] +76

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_selftest@live_evict:
    - fi-bsw-kefka:       PASS -> DMESG-WARN [fdo#107709]

  * igt@kms_busy@basic-flip-c:
    - fi-pnv-d510:        NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
    - fi-byt-clapper:     PASS -> FAIL [fdo#103191] / [fdo#107362]

  * igt@runner@aborted:
    - fi-bsw-kefka:       NOTRUN -> FAIL [fdo#107709]

  
#### Possible fixes ####

  * igt@i915_module_load@reload-with-fault-injection:
    - fi-kbl-7567u:       DMESG-WARN [fdo#105602] / [fdo#108529] -> PASS +1

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-7567u:       DMESG-WARN [fdo#108529] -> PASS

  * igt@i915_selftest@live_hugepages:
    - {fi-icl-y}:         INCOMPLETE [fdo#109663] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-7567u:       DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] -> PASS

  * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
    - fi-byt-clapper:     FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - fi-kbl-7567u:       DMESG-FAIL [fdo#105079] -> PASS

  * igt@prime_vgem@basic-fence-flip:
    - fi-gdg-551:         FAIL [fdo#103182] -> PASS
    - fi-kbl-7567u:       SKIP [fdo#109271] -> PASS +4

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109663]: https://bugs.freedesktop.org/show_bug.cgi?id=109663


Participating hosts (46 -> 42)
------------------------------

  Additional (1): fi-pnv-d510 
  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bdw-samus 


Build changes
-------------

    * IGT: IGT_4871 -> IGTPW_2556

  CI_DRM_5706: fac7596f4bfed7dbaa19ce37bbb35bb50234438e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2556: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2556/
  IGT_4871: 8feb147562ba1b364615ddacd44c3846f0250d37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

[igt-dev] ✓ Fi.CI.IGT: success for series starting with [i-g-t,1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Patchwork]

== Series Details ==

Series: series starting with [i-g-t,1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster
URL   : https://patchwork.freedesktop.org/series/57592/
State : success

== Summary ==

CI Bug Log - changes from IGT_4871_full -> IGTPW_2556_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_schedule@preempt-other-chain-blt:
    - shard-snb:          NOTRUN -> SKIP [fdo#109271] +68

  * igt@gem_pwrite@huge-cpu-backwards:
    - shard-glk:          NOTRUN -> SKIP [fdo#109271] +31

  * igt@i915_pm_rpm@gem-execbuf-stress-pc8:
    - shard-hsw:          NOTRUN -> SKIP [fdo#109271] +39

  * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
    - shard-apl:          PASS -> FAIL [fdo#109660]
    - shard-kbl:          PASS -> FAIL [fdo#109660]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
    - shard-hsw:          PASS -> DMESG-WARN [fdo#107956] +1
    - shard-kbl:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
    - shard-glk:          NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-hang-oldfb-render-e:
    - shard-kbl:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
    - shard-apl:          PASS -> FAIL [fdo#106510] / [fdo#108145]
    - shard-kbl:          PASS -> FAIL [fdo#107725] / [fdo#108145]

  * igt@kms_concurrent@pipe-d:
    - shard-glk:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_cursor_crc@cursor-128x128-onscreen:
    - shard-apl:          PASS -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-random:
    - shard-kbl:          PASS -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-64x21-sliding:
    - shard-glk:          NOTRUN -> FAIL [fdo#103232]

  * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
    - shard-glk:          PASS -> FAIL [fdo#100368]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
    - shard-kbl:          PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
    - shard-apl:          PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
    - shard-glk:          PASS -> FAIL [fdo#103167] +5

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt:
    - shard-kbl:          NOTRUN -> SKIP [fdo#109271] +23

  * igt@kms_plane@pixel-format-pipe-a-planes:
    - shard-kbl:          PASS -> FAIL [fdo#103166] +2

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
    - shard-kbl:          NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
    - shard-apl:          PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
    - shard-glk:          PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_scaling@pipe-c-plane-scaling:
    - shard-hsw:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_rotation_crc@multiplane-rotation:
    - shard-kbl:          PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_setmode@basic:
    - shard-apl:          PASS -> FAIL [fdo#99912]

  * igt@kms_vblank@pipe-c-query-forked-hang:
    - shard-snb:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
    - shard-apl:          PASS -> FAIL [fdo#104894]
    - shard-kbl:          PASS -> FAIL [fdo#104894]

  
#### Possible fixes ####

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
    - shard-hsw:          DMESG-WARN [fdo#107956] -> PASS
    - shard-kbl:          DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_color@pipe-a-ctm-max:
    - shard-kbl:          FAIL [fdo#108147] -> PASS
    - shard-apl:          FAIL [fdo#108147] -> PASS

  * igt@kms_color@pipe-a-degamma:
    - shard-apl:          FAIL [fdo#104782] / [fdo#108145] -> PASS
    - shard-kbl:          FAIL [fdo#104782] / [fdo#108145] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-onscreen:
    - shard-apl:          FAIL [fdo#103232] -> PASS +3
    - shard-kbl:          FAIL [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-alpha-opaque:
    - shard-apl:          FAIL [fdo#109350] -> PASS
    - shard-glk:          FAIL [fdo#109350] -> PASS

  * igt@kms_cursor_crc@cursor-size-change:
    - shard-glk:          FAIL [fdo#103232] -> PASS

  * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
    - shard-glk:          FAIL [fdo#105454] / [fdo#106509] -> PASS

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          FAIL [fdo#105363] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
    - shard-kbl:          FAIL [fdo#103167] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
    - shard-apl:          FAIL [fdo#103167] -> PASS +2

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
    - shard-glk:          FAIL [fdo#103167] -> PASS +5

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
    - shard-apl:          FAIL [fdo#103166] -> PASS +5

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
    - shard-glk:          FAIL [fdo#108145] -> PASS +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
    - shard-glk:          FAIL [fdo#103166] -> PASS +8

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
    - shard-kbl:          FAIL [fdo#103166] -> PASS +2

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
    - shard-apl:          FAIL [fdo#104894] -> PASS +1
    - shard-kbl:          FAIL [fdo#104894] -> PASS

  * igt@perf@oa-formats:
    - shard-hsw:          INCOMPLETE [fdo#103540] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
  [fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105454]: https://bugs.freedesktop.org/show_bug.cgi?id=105454
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#106509]: https://bugs.freedesktop.org/show_bug.cgi?id=106509
  [fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
  [fdo#107725]: https://bugs.freedesktop.org/show_bug.cgi?id=107725
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
  [fdo#109660]: https://bugs.freedesktop.org/show_bug.cgi?id=109660
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (6 -> 5)
------------------------------

  Missing    (1): shard-skl 


Build changes
-------------

    * IGT: IGT_4871 -> IGTPW_2556

  CI_DRM_5706: fac7596f4bfed7dbaa19ce37bbb35bb50234438e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2556: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2556/
  IGT_4871: 8feb147562ba1b364615ddacd44c3846f0250d37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Caz Yokoyama]

On Tue, 2019-03-05 at 17:22 +0000, Chris Wilson wrote:
> Quoting Caz Yokoyama (2019-03-06 00:06:55)
> > Less iterate because WAIT_EXTRA adds extra 5 sec delay for each
> > iteration.
> > This test is similar to gem-execbuf-stress except for WAIT_EXTRA.
> > It runs 86 sec. while gem-execbuf-stress runs 38 sec.
> > i.e. 38s + iteration(rounds,10) * 5s = 88s
> 
> Why does it wait for 5s? There's no second stage to runtime suspend,
> but
> if there was, add a debug interface to force it.
I believe no because teardown_environment() is the onlye statement
after igt_subtest("gem-execbuf-stress-extra-wait").

> Something else that can be employed to speed up this test would be
> igt_drop_caches_set(DROP_IDLE) (before waiting for runtime suspend).
Yes, it does speed up to 56sec from 88sec. Not only gem-execbuf-stress-
extra-wait, but also other 2 tests speed up. For example, gem-execbuf-
stress speed up to 9sec from 38sec. Thank you.

How do you want to have patches? Only igt_drop_caches_set(DROP_IDLE)?
Both igt_drop_caches_set(DROP_IDLE) and rounds / 2 in a single patch?
Separate 2 patches?
-caz

> -Chris

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

Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Chris Wilson]

Quoting Caz Yokoyama (2019-03-05 23:22:06)
> On Tue, 2019-03-05 at 17:22 +0000, Chris Wilson wrote:
> > Quoting Caz Yokoyama (2019-03-06 00:06:55)
> > > Less iterate because WAIT_EXTRA adds extra 5 sec delay for each
> > > iteration.
> > > This test is similar to gem-execbuf-stress except for WAIT_EXTRA.
> > > It runs 86 sec. while gem-execbuf-stress runs 38 sec.
> > > i.e. 38s + iteration(rounds,10) * 5s = 88s
> > 
> > Why does it wait for 5s? There's no second stage to runtime suspend,
> > but
> > if there was, add a debug interface to force it.
> I believe no because teardown_environment() is the onlye statement
> after igt_subtest("gem-execbuf-stress-extra-wait").

I mean in the kernel. I can't think what the extra 5s does, my guess
would be that it was to try and induce some HW change. (But by the time
runtime suspend completes, the HW *should* be as powered down as we can
achieve.)

Something that may help a bit is by adding something like
pm_runtime_force_suspend() to a debug path, like DROP_SUSPEND.

> > Something else that can be employed to speed up this test would be
> > igt_drop_caches_set(DROP_IDLE) (before waiting for runtime suspend).
> Yes, it does speed up to 56sec from 88sec. Not only gem-execbuf-stress-
> extra-wait, but also other 2 tests speed up. For example, gem-execbuf-
> stress speed up to 9sec from 38sec. Thank you.
> 
> How do you want to have patches? Only igt_drop_caches_set(DROP_IDLE)?
> Both igt_drop_caches_set(DROP_IDLE) and rounds / 2 in a single patch?
> Separate 2 patches?

2 patches. Adding DROP_IDLE is definitely a functional change (that
should have no impact on behaviour) that wants to be separate. Doing
exactly the same operations faster is one thing; doing fewer operations
altogether requires some more handwaving as why you think that is
justified, and why that is important enough to take a risk.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Caz Yokoyama]

Less iterate because WAIT_EXTRA adds extra 5 sec delay for each iteration.
This test is similar to gem-execbuf-stress except for WAIT_EXTRA.
It runs 86 sec. while gem-execbuf-stress runs 38 sec.
i.e. 38s + iteration(rounds,10) * 5s = 88s

In case of modeset-stress-extra-wait, iteration is reduced to half.
Do same for gem-execbuf-stress-extra-wait.

Execution time becomes 44 sec.

Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
---
 tests/i915/i915_pm_rpm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index be296f52..a52ecbb0 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -2083,8 +2083,10 @@ int main(int argc, char *argv[])
 		gem_execbuf_stress_subtest(rounds, WAIT_STATUS);
 	igt_subtest("gem-execbuf-stress-pc8")
 		gem_execbuf_stress_subtest(rounds, WAIT_PC8_RES);
+	/* less iteration because of WAIT_EXTRA, i.e. 5 sec delay */
 	igt_subtest("gem-execbuf-stress-extra-wait")
-		gem_execbuf_stress_subtest(rounds, WAIT_STATUS | WAIT_EXTRA);
+		gem_execbuf_stress_subtest(rounds / 2,
+					   WAIT_STATUS | WAIT_EXTRA);
 
 	/* power-wake reference tests */
 	igt_subtest("pm-tiling")
-- 
2.17.1

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

Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Caz Yokoyama]

On Tue, 2019-03-05 at 23:29 +0000, Chris Wilson wrote:
> Quoting Caz Yokoyama (2019-03-05 23:22:06)
> > On Tue, 2019-03-05 at 17:22 +0000, Chris Wilson wrote:
> > > Quoting Caz Yokoyama (2019-03-06 00:06:55)
> > > > Less iterate because WAIT_EXTRA adds extra 5 sec delay for each
> > > > iteration.
> > > > This test is similar to gem-execbuf-stress except for
> > > > WAIT_EXTRA.
> > > > It runs 86 sec. while gem-execbuf-stress runs 38 sec.
> > > > i.e. 38s + iteration(rounds,10) * 5s = 88s
> > > 
> > > Why does it wait for 5s? There's no second stage to runtime
> > > suspend,
> > > but
> > > if there was, add a debug interface to force it.
> > 
> > I believe no because teardown_environment() is the onlye statement
> > after igt_subtest("gem-execbuf-stress-extra-wait").
> 
> I mean in the kernel. I can't think what the extra 5s does, my guess
> would be that it was to try and induce some HW change. (But by the
> time
> runtime suspend completes, the HW *should* be as powered down as we
> can
> achieve.)
> 
> Something that may help a bit is by adding something like
> pm_runtime_force_suspend() to a debug path, like DROP_SUSPEND.
Are you advicing to replace WAIT_EXTRA by DROP_SUSPEND? By DROP_IDLE,
queueued requests are dropped, therefore, wait_for_suspended() becomes
shorter. By DROP_SUSPEND, gpu goes to suspended state and no need to
call wait_for_suspended(). The purpose of the test is "let's see what
happens when we force many suspend/resume cycles". So it is OK to force
to suspend. Do I understand your comment correctly?
-caz

> > > Something else that can be employed to speed up this test would
> > > be
> > > igt_drop_caches_set(DROP_IDLE) (before waiting for runtime
> > > suspend).
> > 
> > Yes, it does speed up to 56sec from 88sec. Not only gem-execbuf-
> > stress-
> > extra-wait, but also other 2 tests speed up. For example, gem-
> > execbuf-
> > stress speed up to 9sec from 38sec. Thank you.
> > 
> > How do you want to have patches? Only
> > igt_drop_caches_set(DROP_IDLE)?
> > Both igt_drop_caches_set(DROP_IDLE) and rounds / 2 in a single
> > patch?
> > Separate 2 patches?
> 
> 2 patches. Adding DROP_IDLE is definitely a functional change (that
> should have no impact on behaviour) that wants to be separate. Doing
> exactly the same operations faster is one thing; doing fewer
> operations
> altogether requires some more handwaving as why you think that is
> justified, and why that is important enough to take a risk.
> -Chris

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

Re: [igt-dev] [PATCH i-g-t 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster

[Chris Wilson]

Quoting Caz Yokoyama (2019-03-07 18:21:03)
> On Tue, 2019-03-05 at 23:29 +0000, Chris Wilson wrote:
> > Quoting Caz Yokoyama (2019-03-05 23:22:06)
> > > On Tue, 2019-03-05 at 17:22 +0000, Chris Wilson wrote:
> > > > Quoting Caz Yokoyama (2019-03-06 00:06:55)
> > > > > Less iterate because WAIT_EXTRA adds extra 5 sec delay for each
> > > > > iteration.
> > > > > This test is similar to gem-execbuf-stress except for
> > > > > WAIT_EXTRA.
> > > > > It runs 86 sec. while gem-execbuf-stress runs 38 sec.
> > > > > i.e. 38s + iteration(rounds,10) * 5s = 88s
> > > > 
> > > > Why does it wait for 5s? There's no second stage to runtime
> > > > suspend,
> > > > but
> > > > if there was, add a debug interface to force it.
> > > 
> > > I believe no because teardown_environment() is the onlye statement
> > > after igt_subtest("gem-execbuf-stress-extra-wait").
> > 
> > I mean in the kernel. I can't think what the extra 5s does, my guess
> > would be that it was to try and induce some HW change. (But by the
> > time
> > runtime suspend completes, the HW *should* be as powered down as we
> > can
> > achieve.)
> > 
> > Something that may help a bit is by adding something like
> > pm_runtime_force_suspend() to a debug path, like DROP_SUSPEND.
> Are you advicing to replace WAIT_EXTRA by DROP_SUSPEND? By DROP_IDLE,
> queueued requests are dropped, therefore, wait_for_suspended() becomes
> shorter. By DROP_SUSPEND, gpu goes to suspended state and no need to
> call wait_for_suspended(). The purpose of the test is "let's see what
> happens when we force many suspend/resume cycles". So it is OK to force
> to suspend. Do I understand your comment correctly?

Yes. The sleep is more or less speculation that the HW does it's own
multilevel powergating behind the scenes, and while bogosities such as
the dmc exist, I don't think that there is any magic in the runtime
suspend paths. Hence sleeping past completion of runtime suspend has
little value and can be safely replaced by an explicit forced suspend
(with the knowledge that if HW does get more complicated in future, we
can put the extra debug logic there). The only case where sleeping would
be useful is to confirm the automatic suspend timers work, but that is a
simple testcase of the timer function, orthogonal to the various "check
that we suspend and wakeup correctly around these tasks" we are doing
here.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev