Re: [PATCH i-g-t v2] tests/intel/gem_exec_endless: Use the per-gt interface to set frequencies

[Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>]

Hi Krzysztof,

Thanks for explanation.  Based on that ...

On Thu, 2026-04-09 at 13:46 +0200, Krzysztof Niemiec wrote:
> On 2026-04-07 at 13:42:20 GMT, Janusz Krzysztofik wrote:
> > Hi Krzysztof,
> > 
> > On Tue, 2026-04-07 at 12:52 +0200, Krzysztof Niemiec wrote:
> > > The test alters the environment, specifically the gt frequencies, for
> > > its duration. Using the legacy interface however makes it impossible for
> > > the pre-test state to be restored due to its limitations in multi-gt
> > > systems. 

... because each gt may accept values from a different range and default to
a different value that we may want to restore.

Or something similar.  That won't be too verbose, I believe.

Thanks,
Janusz


> > > Use the per-gt interface instead to properly clean up.
> > 
> > While I think your solution may be correct, your description is not clear 
> > enough for me.  How is it possible for the legacy interface to work as 
> > expected when altering the environment, but not ant longer when restoring 
> > defaults?
> > 
> 
> The legacy interface can only ever emit a singular value to the GTs (the
> same value to all at once), while the per-gt interface allows granular
> control.
> 
> So, for example, say we have two GTs - gt0 and gt1. You can set the
> frequency values (min_freq, max_freq, boost_freq are the ones set by the
> test) to those that fall in the range in between RPn and RP0. These
> values can be different for different GTs, these are from the test box
> I've been testing the patch on:
> 
> 	root@box:/sys/class/drm/card1# cat gt/gt0/rps_RPn_freq_mhz
> 	800
> 	root@box:/sys/class/drm/card1# cat gt/gt1/rps_RPn_freq_mhz
> 	100
> 
> 	root@box:/sys/class/drm/card1# cat gt/gt0/rps_RP0_freq_mhz
> 	2200
> 	root@box:/sys/class/drm/card1# cat gt/gt1/rps_RP0_freq_mhz
> 	1300
> 
> So gt0 accepts values from the range 800-2200, but gt1 accepts values
> from the range 100-1300.
> 
> However, the legacy interface reports only one set of these values:
> 
> 	root@box:/sys/class/drm/card1# cat gt_RPn_freq_mhz
> 	800
> 	root@box:/sys/class/drm/card1# cat gt_RP0_freq_mhz
> 	2200
> 
> Now, without the patch, the test looks at the legacy interface's RP0 and
> RPn value to alter the environment, showing a range of 800-2200. The
> test sets all frequencies to max (so 2200, as read from the legacy
> interface). This actually fails silently for gt1 in this example:
> 
> 	root@box:/sys/class/drm/card1# echo 1300 > gt_min_freq_mhz
> 	root@box:/sys/class/drm/card1# echo 2200 > gt_min_freq_mhz
> 	-bash: echo: write error: Invalid argument
> 
> (the failure is silent because the test doesn't check for a return value).
> gt0 is set properly, gt1 stays at 100. This is because we cannot have
> the information for gt1's range of allowed values, since the legacy
> interface reports the max of these two. Changing it to the minimum of
> the two values will prevent a failure in gt1, but then gt0 will be set
> to 1300 while it can be still raised to 2200, so we're not actually
> setting the maximum value for it, which the test is trying to do. The
> per-gt interface just treats both GTs independently, reading the correct
> range for all of them, so this issue doesn't arise.
> 
> Then, after the test is finished, the test tries to set the values back
> to what RP0 and RPn report. Let's look at the min_freq because this is a
> cause for problems in further tests that expect a restored environment.
> 
> After test init, as I described earlier, the values for min_freq are
> 2200 and 100 for gt0 and gt1 respectively. During cleanup, the test reads
> RPn from the legacy interface, which is 800, and then sets the min_freq
> (using the legacy interface too) to this value. Now, since 800 is both in
> the 100-1300 and the 800-2200 range, this will succeed; after this values
> for min_freq are 800 and 800 for gt0 and gt1. This is a mismatch with
> the original values being 800 and 100 for gt0 and gt1.
> 
> Note that reporting 100 from the legacy interface instead won't fix the
> problem either, as then min_freq for gt1 would be correctly set to 100,
> but setting it for gt0 would fail (100 is not in 800-2200), so the test
> would leave the values at 2200 and 100, respectively, still not
> restoring the environment properly. This is just impossible to
> accomplish using the legacy interface, because it can only ever report a
> single value for any of the attributes.
> 
> To explain this in detail could be unneccesarily verbose for a git log,
> but if you think it's needed, I can include it.
> 
> Thanks
> Krzysztof
> 
> > Thanks,
> > Janusz
> >