[PATCH v2 0/8] Engine Busyness

[Tvrtko Ursulin]

On 14/12/2023 01:56, Umesh Nerlige Ramappa wrote:
> On Thu, Dec 07, 2023 at 02:45:47PM +0000, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 07/12/2023 12:57, Riana Tauro wrote:
>>> GuC provides engine busyness ticks as a 64 bit counter which count
>>> as clock ticks. These counters are maintained in a
>>> shared memory buffer and internally updated on a continuous basis.
>>>
>>> GuC also provides a periodically total active ticks that GT has been
>>> active for. This counter is exposed to the user such that busyness can
>>> be calculated as a percentage using
>>>
>>> busyness % = (engine active ticks/total active ticks) * 100.
>>
>> I think I've asked this before but don't remember it was clarified - 
>> what are the semantics of "active" with total active ticks? In other 
>> words considering activity timelines like:
>>
>> 1)
>>     0          1s
>> rcs0 |xxxxx-----|
>> bcs0 |-----xxxxx|
>>
>> 2)
>>     0          1s
>> rcs0 |xxxxx-----|
>> bcs0 |xxxxx-----|
>>
>> Assuming 1s sampling, would the above formula correctly say 50% for 
>> both engines in both cases?
> 
> Yes. What is the significance of case 2? Are you saying rcs and bcs are 
> executing in parallel?

In parallel yes. Complete overlap, no overlap, or any overlap of 
activity in between the two.

> Either ways, when total active ticks is queried it would provide the 
> latest value of the active time (does not depend on gt park/unpark since 
> the value is either obtained on demand from GuC or is a value that is 
> frequently updated by GuC.
> 
> The duration of context (in to out) is accumulated for the each engine.

But why is the total *active* tick moving during the 0.5s - 1s time of 
the 2nd diagram though? What does it mean by "active" if nothing was 
active during that period?

>> I am also curious if there are plans to add support to intel_gpu_top 
>> in which case please copy me on the required refactorings.
>>
> 
> Certainly. It's in the works.

Cool.

Regards,

Tvrtko