[Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

Ville Syrjälä ville.syrjala at linux.intel.com
Tue Oct 18 09:23:30 UTC 2016


On Tue, Oct 18, 2016 at 12:03:12PM +0300, Petri Latvala wrote:
> On Tue, Oct 18, 2016 at 09:34:49AM +0200, Daniel Vetter wrote:
> > Re S4: If it indeed improves coverage (i.e. calls our shutdown hooks and
> > all these S4-only callbacks) then adding it to BAT sounds reasonable.
> > Still there's the issue of where to get the machine time from. I really do
> > think you need to first trade in some speed-up here (or throw out some
> > other tests) before you can add more tests.
> 
> For the record, the runtimes of all tests in CI can be found in the
> result-runtimes.log file, within the test log directory.
> 
> Over 10s runtimes on a randomly selected machine are:
> 
> 31.92 igt at gem_ctx_switch@basic-default-heavy
> 22.91 igt at gem_busy@basic-hang-default
> 21.03 igt at kms_flip@basic-flip-vs-dpms
> 20.96 igt at kms_flip@basic-flip-vs-modeset
> 20.39 igt at gem_ctx_switch@basic-default
> 20.30 igt at gem_exec_create@basic
> 20.11 igt at gem_ctx_create@basic-files
> 19.64 igt at kms_pipe_crc_basic@suspend-read-crc-pipe-a
> 18.93 igt at kms_pipe_crc_basic@suspend-read-crc-pipe-b
> 18.91 igt at kms_pipe_crc_basic@suspend-read-crc-pipe-c
> 18.76 igt at gem_exec_suspend@basic-s3
> 17.98 igt at kms_pipe_crc_basic@hang-read-crc-pipe-c
> 16.70 igt at kms_flip@basic-flip-vs-wf_vblank
> 14.17 igt at kms_pipe_crc_basic@hang-read-crc-pipe-a
> 14.14 igt at gem_exec_nop@basic-parallel
> 14.12 igt at gem_exec_nop@basic-series
> 13.76 igt at kms_pipe_crc_basic@hang-read-crc-pipe-b
> 12.70 igt at gem_ringfill@basic-default-hang
> 11.34 igt at drv_hangman@error-state-basic
> 10.91 igt at gem_sync@basic-many-each
> 10.81 igt at gem_close_race@basic-threads
> 10.73 igt at kms_flip@basic-plain-flip
> 10.33 igt at gem_sync@basic-store-each
> 10.29 igt at gem_sync@basic-store-all
> 10.11 igt at gem_sync@basic-each
> 10.08 igt at gem_sync@basic-all
> 
> Does any of these strike as a low-hanging fruit?

s/15/5/ for the S3 delay I'd say. If there's a machine that won't work
with 5 seconds, then we find out what's the lowest safe value and use
that instead. 15 seconds is excessive on all the machines I've seen.
And maybe make these delays configurabe via env variables so that I
don't have to keep patching igt when I want to test suspendy stuff ;)

-- 
Ville Syrjälä
Intel OTC


More information about the Intel-gfx mailing list