Re: [PATCH i-g-t 14/16] i915/gem_exec_balancer: Exercise bonded pairs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 15/05/2019 21:32, Chris Wilson wrote:
Quoting Chris Wilson (2019-05-15 20:57:18)
Quoting Tvrtko Ursulin (2019-05-15 11:58:20)

On 08/05/2019 11:09, Chris Wilson wrote:
+                     igt_assert_f(load > 0.90,
+                                  "engine %d (class:instance %d:%d) was found to be only %.1f%% busy\n",
+                                  n, siblings[n].engine_class, siblings[n].engine_instance,
+                                  load*100);

Master also needs to be checked I think. You have the infrastructure to
open two pmus in the previous patch so should be easy.

Haven't we checked precisely that in earlier tests? What would perhaps

Where? I see one subtest for bonding.

be fairer here would be to verify the other engine was idle, otherwise
we could say we fluked it. Furthermore, we should repeat a few times
with say (0, 1), (0, 1), (1, 0), (1, 0) to further rule out flukes, and
then to finish with a random smoketest of some description.

Hm maybe gpu idling before each pass is needed in this test.

Then I'd be happy if you just measured busyness on a bonded pair.

And yeah more permutation would be good for fluke prevention.

Perhaps even a test is closer to the typical workload would involve
semaphore communication across the bond. But I don't know a way in which
I can determine which engine I am on in order to record that from the
GPU itself.

To remind myself, the importance here is on uABI stressing, it's is much
easier to prove the relationship in the kernel and that is where we do.

I didn't think it would be hard to read busyness from the master as well but if you insist okay.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux