[Intel-gfx] [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 Intel-gfx
mailing list