[i-g-t] i915/gem_mmap_gtt: Run forked mmap tests on tgl
diff mbox series

Message ID 20190917112348.31500-1-chris@chris-wilson.co.uk
State New
Headers show
Series
  • [i-g-t] i915/gem_mmap_gtt: Run forked mmap tests on tgl
Related show

Commit Message

Chris Wilson Sept. 17, 2019, 11:23 a.m. UTC
Tigerlake does not seem to be suffering from the same fault as Icelake
did, so let the tests run as they should complete within the timeout.

Early tgl results:

basic-small-copy: SUCCESS (1,671s)
forked-basic-small-copy: SUCCESS (37,568s)

medium-copy: SUCCESS (3,307s)
forked-medium-copy: SUCCESS (76,614s)
forked-medium-copy-XY: SUCCESS (203,251s)
forked-medium-copy-odd: SUCCESS (204,265s)

Not great, but nowhere near as bad as icl,
       single      forked
glk:    2.15s       2.89s
icl:    2.50s     281.08s

References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
 tests/i915/gem_mmap_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Martin Peres Sept. 17, 2019, 11:37 a.m. UTC | #1
On 17/09/2019 14:23, Chris Wilson wrote:
> Tigerlake does not seem to be suffering from the same fault as Icelake
> did, so let the tests run as they should complete within the timeout.
> 
> Early tgl results:
> 
> basic-small-copy: SUCCESS (1,671s)
> forked-basic-small-copy: SUCCESS (37,568s)
> 
> medium-copy: SUCCESS (3,307s)
> forked-medium-copy: SUCCESS (76,614s)
> forked-medium-copy-XY: SUCCESS (203,251s)
> forked-medium-copy-odd: SUCCESS (204,265s)

Thanks for checking this out!

3 minutes for a subtest is still an eternity... How much lost coverage
would it be if we did not execute the non-small forked test?

Martin

> 
> Not great, but nowhere near as bad as icl,
>        single      forked
> glk:    2.15s       2.89s
> icl:    2.50s     281.08s
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Martin Peres <martin.peres@linux.intel.com>
> ---
>  tests/i915/gem_mmap_gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
> index ac439cdf8..e2c6ad9a0 100644
> --- a/tests/i915/gem_mmap_gtt.c
> +++ b/tests/i915/gem_mmap_gtt.c
> @@ -792,7 +792,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int tiling_b, int ncpus)
>  	uint64_t huge_object_size, i;
>  	unsigned mode = CHECK_RAM;
>  
> -	igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
> +	igt_fail_on_f(intel_gen(devid) == 11 && ncpus > 1,
>  		      "Please adjust your expectations, https://bugs.freedesktop.org/show_bug.cgi?id=110882\n");
>  
>  	switch (huge) {
>
Chris Wilson Sept. 17, 2019, 11:42 a.m. UTC | #2
Quoting Martin Peres (2019-09-17 12:37:25)
> 
> 
> On 17/09/2019 14:23, Chris Wilson wrote:
> > Tigerlake does not seem to be suffering from the same fault as Icelake
> > did, so let the tests run as they should complete within the timeout.
> > 
> > Early tgl results:
> > 
> > basic-small-copy: SUCCESS (1,671s)
> > forked-basic-small-copy: SUCCESS (37,568s)
> > 
> > medium-copy: SUCCESS (3,307s)
> > forked-medium-copy: SUCCESS (76,614s)
> > forked-medium-copy-XY: SUCCESS (203,251s)
> > forked-medium-copy-odd: SUCCESS (204,265s)
> 
> Thanks for checking this out!
> 
> 3 minutes for a subtest is still an eternity... How much lost coverage
> would it be if we did not execute the non-small forked test?

The others check out the partial fencing, which in theory is checked
extensively in the selftests (live_mman). It shouldn't be an issue, but
it was the forked-medium-copy that hit the timeout and so warned us
about icl. ~o~

* starts playing on his tiny fiddle to the tune of EzBench
-Chris
Mika Kuoppala Sept. 17, 2019, 12:04 p.m. UTC | #3
Chris Wilson <chris@chris-wilson.co.uk> writes:

> Tigerlake does not seem to be suffering from the same fault as Icelake
> did, so let the tests run as they should complete within the timeout.
>
> Early tgl results:
>
> basic-small-copy: SUCCESS (1,671s)
> forked-basic-small-copy: SUCCESS (37,568s)
>
> medium-copy: SUCCESS (3,307s)
> forked-medium-copy: SUCCESS (76,614s)
> forked-medium-copy-XY: SUCCESS (203,251s)
> forked-medium-copy-odd: SUCCESS (204,265s)
>
> Not great, but nowhere near as bad as icl,
>        single      forked
> glk:    2.15s       2.89s
> icl:    2.50s     281.08s
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Martin Peres <martin.peres@linux.intel.com>
> ---
>  tests/i915/gem_mmap_gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
> index ac439cdf8..e2c6ad9a0 100644
> --- a/tests/i915/gem_mmap_gtt.c
> +++ b/tests/i915/gem_mmap_gtt.c
> @@ -792,7 +792,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int tiling_b, int ncpus)
>  	uint64_t huge_object_size, i;
>  	unsigned mode = CHECK_RAM;
>  
> -	igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
> +	igt_fail_on_f(intel_gen(devid) == 11 && ncpus > 1,
>  		      "Please adjust your expectations, https://bugs.freedesktop.org/show_bug.cgi?id=110882\n");

It seems to be still exponential so how about,

if (intel_gen(devid) >= 11)
   ncpus = max(2, (ncpus-1)/2);

Would drop the medium-odd to 14 seconds, without huge dent in coverage as
as odd number of cpus would be bouncing on it?

-Mika

>  
>  	switch (huge) {
> -- 
> 2.23.0
Chris Wilson Sept. 17, 2019, 12:13 p.m. UTC | #4
Quoting Mika Kuoppala (2019-09-17 13:04:32)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > Tigerlake does not seem to be suffering from the same fault as Icelake
> > did, so let the tests run as they should complete within the timeout.
> >
> > Early tgl results:
> >
> > basic-small-copy: SUCCESS (1,671s)
> > forked-basic-small-copy: SUCCESS (37,568s)
> >
> > medium-copy: SUCCESS (3,307s)
> > forked-medium-copy: SUCCESS (76,614s)
> > forked-medium-copy-XY: SUCCESS (203,251s)
> > forked-medium-copy-odd: SUCCESS (204,265s)
> >
> > Not great, but nowhere near as bad as icl,
> >        single      forked
> > glk:    2.15s       2.89s
> > icl:    2.50s     281.08s
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Cc: Martin Peres <martin.peres@linux.intel.com>
> > ---
> >  tests/i915/gem_mmap_gtt.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
> > index ac439cdf8..e2c6ad9a0 100644
> > --- a/tests/i915/gem_mmap_gtt.c
> > +++ b/tests/i915/gem_mmap_gtt.c
> > @@ -792,7 +792,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int tiling_b, int ncpus)
> >       uint64_t huge_object_size, i;
> >       unsigned mode = CHECK_RAM;
> >  
> > -     igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
> > +     igt_fail_on_f(intel_gen(devid) == 11 && ncpus > 1,
> >                     "Please adjust your expectations, https://bugs.freedesktop.org/show_bug.cgi?id=110882\n");
> 
> It seems to be still exponential so how about,
> 
> if (intel_gen(devid) >= 11)
>    ncpus = max(2, (ncpus-1)/2);
> 
> Would drop the medium-odd to 14 seconds, without huge dent in coverage as
> as odd number of cpus would be bouncing on it?

My worry is that our discovery that they introduced this late change
into Icelake is pure serendipity, and so I hesitate deviating too far
from the test setup that originally found the problem. I'd rather extend
the testing to study the correlation between ncpus and time than reduce
it :(

Thinking about the effects worth investigating here, doing a cpuset to
bind the process to a single cpu, then forking two processes should
minimally cover the uabi behaviour.
-Chris

Patch
diff mbox series

diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index ac439cdf8..e2c6ad9a0 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -792,7 +792,7 @@  test_huge_copy(int fd, int huge, int tiling_a, int tiling_b, int ncpus)
 	uint64_t huge_object_size, i;
 	unsigned mode = CHECK_RAM;
 
-	igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
+	igt_fail_on_f(intel_gen(devid) == 11 && ncpus > 1,
 		      "Please adjust your expectations, https://bugs.freedesktop.org/show_bug.cgi?id=110882\n");
 
 	switch (huge) {