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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Thu May 16 09:28:40 UTC 2019


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


More information about the igt-dev mailing list