| Message ID | 20191101105106.12297-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [i-g-t] intel-ci: Relegate gem_exec_reloc to the shards | expand |
Quoting Chris Wilson (2019-11-01 10:51:06) > The gem_exec_reloc basic subtests cover a couple dozen basic ABI > sanitychecks, aiming to prove the ABI works. While relocations used to > be essential, they are no longer the basis of current clients who all > softpin. It is a stagnant portion of the ABI that does not contribute > much to overall driver health (the complicated portions of relocs are > covered in the smoketests like gem_exec_parallel and gem_exec_gttfill). > However, even though each of the basic subtest is trivial and runs in > very little time, since CI is running each individually the time between > tests mounts up (especially on eMMC devices like fi-kbl-soraka). > > By moving these tests to the shards we should speed up BAT on the > ratelimiting fi-kbl-soraka, while losing no coverage overall -- and > hopefully without losing any of the predictive failure coverage in BAT. > This stagnant bit of uAPI/uABI will remain checked by the irregular idle > runs. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> > Cc: Petri Latvala <petri.latvala@intel.com> > Cc: Martin Peres <martin.peres@linux.intel.com> Before Joonas went fishing, he gave +1. So, Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Tomi, Petri, Martin any objections? -Chris
On Fri, Nov 01, 2019 at 10:56:37AM +0000, Chris Wilson wrote: > Quoting Chris Wilson (2019-11-01 10:51:06) > > The gem_exec_reloc basic subtests cover a couple dozen basic ABI > > sanitychecks, aiming to prove the ABI works. While relocations used to > > be essential, they are no longer the basis of current clients who all > > softpin. It is a stagnant portion of the ABI that does not contribute > > much to overall driver health (the complicated portions of relocs are > > covered in the smoketests like gem_exec_parallel and gem_exec_gttfill). > > However, even though each of the basic subtest is trivial and runs in > > very little time, since CI is running each individually the time between > > tests mounts up (especially on eMMC devices like fi-kbl-soraka). > > > > By moving these tests to the shards we should speed up BAT on the > > ratelimiting fi-kbl-soraka, while losing no coverage overall -- and > > hopefully without losing any of the predictive failure coverage in BAT. > > This stagnant bit of uAPI/uABI will remain checked by the irregular idle > > runs. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> > > Cc: Petri Latvala <petri.latvala@intel.com> > > Cc: Martin Peres <martin.peres@linux.intel.com> > > Before Joonas went fishing, he gave +1. So, > Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Tomi, Petri, Martin any objections? > -Chris Acked-by: Petri Latvala <petri.latvala@intel.com>
On 11/1/19 1:21 PM, Petri Latvala wrote: > On Fri, Nov 01, 2019 at 10:56:37AM +0000, Chris Wilson wrote: >> Quoting Chris Wilson (2019-11-01 10:51:06) >>> The gem_exec_reloc basic subtests cover a couple dozen basic ABI >>> sanitychecks, aiming to prove the ABI works. While relocations used to >>> be essential, they are no longer the basis of current clients who all >>> softpin. It is a stagnant portion of the ABI that does not contribute >>> much to overall driver health (the complicated portions of relocs are >>> covered in the smoketests like gem_exec_parallel and gem_exec_gttfill). >>> However, even though each of the basic subtest is trivial and runs in >>> very little time, since CI is running each individually the time between >>> tests mounts up (especially on eMMC devices like fi-kbl-soraka). >>> >>> By moving these tests to the shards we should speed up BAT on the >>> ratelimiting fi-kbl-soraka, while losing no coverage overall -- and >>> hopefully without losing any of the predictive failure coverage in BAT. >>> This stagnant bit of uAPI/uABI will remain checked by the irregular idle >>> runs. >>> >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> >>> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> >>> Cc: Petri Latvala <petri.latvala@intel.com> >>> Cc: Martin Peres <martin.peres@linux.intel.com> >> >> Before Joonas went fishing, he gave +1. So, >> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> >> >> Tomi, Petri, Martin any objections? >> -Chris > > Acked-by: Petri Latvala <petri.latvala@intel.com> Looks reasonable, and I like it. Acked-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index 2553a68c3..ade739694 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -26,34 +26,6 @@ igt@gem_exec_gttfill@basic igt@gem_exec_parallel@basic igt@gem_exec_parse@basic-allowed igt@gem_exec_parse@basic-rejected -igt@gem_exec_reloc@basic-cpu -igt@gem_exec_reloc@basic-gtt -igt@gem_exec_reloc@basic-cpu-gtt -igt@gem_exec_reloc@basic-gtt-cpu -igt@gem_exec_reloc@basic-cpu-read -igt@gem_exec_reloc@basic-gtt-read -igt@gem_exec_reloc@basic-write-cpu -igt@gem_exec_reloc@basic-write-gtt -igt@gem_exec_reloc@basic-write-read -igt@gem_exec_reloc@basic-cpu-noreloc -igt@gem_exec_reloc@basic-gtt-noreloc -igt@gem_exec_reloc@basic-cpu-gtt-noreloc -igt@gem_exec_reloc@basic-gtt-cpu-noreloc -igt@gem_exec_reloc@basic-cpu-read-noreloc -igt@gem_exec_reloc@basic-gtt-read-noreloc -igt@gem_exec_reloc@basic-write-cpu-noreloc -igt@gem_exec_reloc@basic-write-gtt-noreloc -igt@gem_exec_reloc@basic-write-read-noreloc -igt@gem_exec_reloc@basic-cpu-active -igt@gem_exec_reloc@basic-gtt-active -igt@gem_exec_reloc@basic-cpu-gtt-active -igt@gem_exec_reloc@basic-gtt-cpu-active -igt@gem_exec_reloc@basic-cpu-read-active -igt@gem_exec_reloc@basic-gtt-read-active -igt@gem_exec_reloc@basic-write-cpu-active -igt@gem_exec_reloc@basic-write-gtt-active -igt@gem_exec_reloc@basic-write-read-active -igt@gem_exec_reloc@basic-softpin igt@gem_exec_store@basic-all igt@gem_exec_suspend@basic igt@gem_exec_suspend@basic-s0
The gem_exec_reloc basic subtests cover a couple dozen basic ABI sanitychecks, aiming to prove the ABI works. While relocations used to be essential, they are no longer the basis of current clients who all softpin. It is a stagnant portion of the ABI that does not contribute much to overall driver health (the complicated portions of relocs are covered in the smoketests like gem_exec_parallel and gem_exec_gttfill). However, even though each of the basic subtest is trivial and runs in very little time, since CI is running each individually the time between tests mounts up (especially on eMMC devices like fi-kbl-soraka). By moving these tests to the shards we should speed up BAT on the ratelimiting fi-kbl-soraka, while losing no coverage overall -- and hopefully without losing any of the predictive failure coverage in BAT. This stagnant bit of uAPI/uABI will remain checked by the irregular idle runs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> --- tests/intel-ci/fast-feedback.testlist | 28 --------------------------- 1 file changed, 28 deletions(-)