[PATCH v9 0/2] drm/xe/pmu: Enable PMU interface

[Aravind Iddamsetty]

On 22/06/24 00:02, Umesh Nerlige Ramappa wrote:
> On Fri, Jun 21, 2024 at 09:59:11AM +0530, Aravind Iddamsetty wrote:
>>
>> On 21/06/24 00:45, Umesh Nerlige Ramappa wrote:
>>> On Fri, Jun 14, 2024 at 08:34:30AM -0700, Dixit, Ashutosh wrote:
>>>> On Thu, 13 Jun 2024 22:50:39 -0700, Riana Tauro wrote:
>>>>>
>>>>> Hi Ashutosh
>>>>>
>>>>> On 6/14/2024 12:09 AM, Dixit, Ashutosh wrote:
>>>>> > On Thu, 13 Jun 2024 03:04:09 -0700, Riana Tauro wrote:
>>>>> >>
>>>>> >
>>>>> > Hi Riana,
>>>>> >
>>>>> >> There are a set of engine group busyness counters provided by HW which are
>>>>> >> perfect fit to be exposed via PMU perf events.
>>>>> >>
>>>>> >> BSPEC: 46559, 46560, 46722, 46729, 52071, 71028
>>>>> >>
>>>>> >> events can be listed using:
>>>>> >> perf list
>>>>> >>    xe_0000_03_00.0/any-engine-group-busy-gt0/         [Kernel PMU event]
>>>>> >>    xe_0000_03_00.0/copy-group-busy-gt0/               [Kernel PMU event]
>>>>> >>    xe_0000_03_00.0/media-group-busy-gt0/              [Kernel PMU event]
>>>>> >>    xe_0000_03_00.0/render-group-busy-gt0/             [Kernel PMU event]
>>>>> >
>>>>> > PMU patches merged previously were dropped in 90a8b23f9b85 ("drm/xe/pmu:
>>>>> > Remove PMU from Xe till uapi is finalized") because PMU uapi was expected
>>>>> > to change. Why are we re-posting these old patches again now, without
>>>>> > including the planned uapi changes?
>>>>>
>>>>> The uapi changes were dropped and there are no other upcoming changes for
>>>>> Group busyness. So re-posted the old series.
>>>>
>>>> What happened to VF busyness (which is why I thought the uapi was going to
>>>> change)?
>>>
>>> There are no plans to support group busyness from a VF, so we are just exporting group busyness to maintain parity with i915 for Native/PF behavior. The only change would be to expose the counters in ticks rather than ns. I still have to look at this series to see if that's happening.
>>
>> how will the counter ticks be used to get the busyness in time
>
> There will be no concept of "busyness in time units". User would just take 2 samples and calculate busyness as a percentage. The counters will be unitless. More info on equation here:
> https://spec.oneapi.io/level-zero/1.9.3/sysman/api.html#_CPPv418zes_engine_stats_t
>
> Percent utilization is calculated by taking two snapshots (s1, s2) and using the equation:
>
> util = (s2.activeTime - s1.activeTime) / (s2.timestamp - s1.timestamp)
>
> Note that zesEngineGetActivity is used to get single as well as group engine busyness from the KMD.
>
> For single engine busyness, KMD will get the information from GuC and that would be a pair of counters - ActiveTicks and TotalActiveTicks corresponding to activeTime and timestamp in the above equation.
>
> For group engine busyness, we should follow the same semantics.

does that mean that the counter itself doesn't have any relevance i mean it doesn't present any outcome to the user and rather one should use some formula to get a usable metric.

so from PMU interface point of view can we expose such a interface, my question because most of the interfaces I found in PMU are directly usable by user.

Thanks,
Aravind.
>
> Regards,
> Umesh
>
>>
>> Regards,
>> Aravind.
>>>
>>> Regards,
>>> Umesh
>>>>
>>>>>
>>>>> Thanks,
>>>>> Riana
>>>>> >
>>>>> > Thanks.
>>>>> > --
>>>>> > Ashutosh