| Message ID | 20190917112348.31500-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [i-g-t] i915/gem_mmap_gtt: Run forked mmap tests on tgl | expand |
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) { >
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
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
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
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) {
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(-)