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

[Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>]

On Mon, Jun 24, 2024 at 03:57:18PM +0530, Aravind Iddamsetty wrote:
>
>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.

Correct.

>
>so from PMU interface point of view can we expose such a interface,

It's still a counter that ticks in one direction, so I believe we should 
be okay using the PMU interface.

> my question because most of the interfaces I found in PMU are directly usable by user.

That's implementation specific. I don't see PMU imposing that 
requirement on us. I agree that it would be intuitive to use the 
counters directly, but this interface is required to work with SRIOV.  
For example, in a VF, the user cannot use the single counter directly to 
determine how busy an engine was. The user also needs to know what 
fraction of wall time the VF ran for. That would help calculate per 
VF/VM based engine utilization/percentage.

Regards,
Umesh

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