[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Run forked mmap tests on tgl

[Chris Wilson]

Quoting Mika Kuoppala (2019-09-17 13:04:32)
> Chris Wilson <chris at 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 at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > Cc: Martin Peres <martin.peres at 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