[igt-dev] [PATCH i-g-t] tests/perf_pmu: Compare against requested freq in frequency subtest

[Tvrtko Ursulin]

On 08/11/2022 01:31, Dixit, Ashutosh wrote:
> On Mon, 07 Nov 2022 16:57:24 -0800, Belgaumkar, Vinay wrote:
>> On 11/7/2022 4:22 PM, Dixit, Ashutosh wrote:
>>> On Mon, 07 Nov 2022 16:18:31 -0800, Dixit, Ashutosh wrote:
>>> Hi Vinay,
>>>
>>> A question for you below.
>>>
>>>> So I submitted this patch to repro the issue and to print out the requested
>>>> freq from sysfs:
>>>>
>>>> https://patchwork.freedesktop.org/series/110630/
>>>>
>>>> And we can see the output here:
>>>>
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8061/bat-dg2-11/igt@perf_pmu@frequency.html
>>>>
>>>> ```
>>>> IGT-Version: 1.26-g1bef4d081 (x86_64) (Linux: 6.1.0-rc4-CI_DRM_12352-gc55ac6a74bd1+ x86_64)
>>>> Starting subtest: frequency
>>>> Frequency: min=300, max=2050, boost=2050 MHz
>>>> Min frequency: requested 349.7, actual 349.7
>>>> Max frequency: requested 2048.0, actual 2048.0
>>>> Sysfs requested: min 350, max 2050
>>>> Stack trace:
>>>>     #0 ../../../usr/src/igt-gpu-tools/lib/igt_core.c:1908 __igt_fail_assert()
>>>>     #1 ../../../usr/src/igt-gpu-tools/tests/i915/perf_pmu.c:1656 __igt_unique____real_main2147()
>>>>     #2 ../../../usr/src/igt-gpu-tools/tests/i915/perf_pmu.c:2147 main()
>>>>     #3 [__libc_start_main+0xf3]
>>>>     #4 [_start+0x2e]
>>>> Subtest frequency: FAIL (2.212s)
>>>> ```
>>>>
>>>> So we clearly see the requested freq from sysfs is indeed 350 MHz so
>>>> SLPC/PCODE is not honoring the set min == max == boost freq (and PMU is
>>>> measuring what sysfs is showing). In general PCODE is the final arbiter in
>>>> such cases and we do occasionally see instances where set freq limits are
>>>> not honored.
>>>>
>>>> I would say if igt at perf_pmu@frequency is testing freq measured by PMU then
>>>> the patch below is correct. Whether SLPC/PCODE is honoring the set freq
>>>> limits should be tested in a SLPC test (which we also have).
>>>
>>> igt at perf_pmu@frequency sets 'min == max == boost == 300 MHz' but we still
>>> see the requested freq to be 350 MHz. Do we have a SLPC test covering this
>>> scenario or should we add one? This is failing on one of the DG2's.
>>
>> Does adding a delay help (around 20 ms for the h2g to go through
>> typically)?
> 
> There is no delay but the test calls gem_quiescent_gpu() after setting 'min
> == max == boost == 300 MHz' and then launches a spinner. We are checking
> the requested freq 500 ms after the spinner is started (so plenty of time
> for the h2g) and still the requested freq is 350 MHz.
> 
>> Also, is there a workload running when we change the min=max=boost to
>> 300?
> 
> No, the workload is started after setting the freq and calling
> gem_quiescent_gpu().

Implication here seems to be that gem_quiescent_gpu() would need to 
cover H2G communication - does it?

>> We already check these things in our SLPC selftests.

Is it then expected to respect the 300MHz max in this case? Or if it 
can't, should it be reflected in the sysfs readback?

Regards,

Tvrtko