Re: [PATCH v2 0/8] Engine Busyness

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 20/12/2023 23:58, Umesh Nerlige Ramappa wrote:
> On Wed, Dec 20, 2023 at 09:00:34AM +0000, Tvrtko Ursulin wrote:
>>
>> On 20/12/2023 05:36, Umesh Nerlige Ramappa wrote:
>>> On Thu, Dec 14, 2023 at 08:06:46AM +0000, Tvrtko Ursulin wrote:
>>>>
>>>> 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.
>>>
>>> GuC accumulates this on context switches, so the overlap does not 
>>> matter.
>>>
>>>>
>>>>> 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?
>>>
>>> VF was still using it's allotted time and hence was active.
>>
>> And if we leave SR-IOV out for a moment?
> 
> Then it is just a periodically sampled (by GuC) value of GT ticks. The 
> period being 100ms.
> 
>>
>> "GuC also provides a periodically total active ticks that GT has been 
>> active for."
>>
>> How many time worth of total GT active ticks does GuC report in 
>> diagram 2 above?
> 
> Every 100ms we would see an updated value. For the duration of 0.5s, it 
> would be 500ms. Sampled at 1s, it will be 1000ms. Until 0.5s it should 
> be 100% busyness but there is an error margin of 100ms. From then on, 
> the busyness % will decrease as time progresses. The error margin is 
> more pronounced for very short workloads, so IGTs were changed to use 2s 
> batch durations rather than 500ms. Haven't checked if IGTs have been 
> posted yet though.

Sorry somehow it is still not clear to me. :)

GuC updates the GT total active ticks _constantly_? With a 100ms 
sampling so like:

a)

  while (true)
    if (gt_active)
       gt_total_active += 100ms
    sleep(100ms)

Or b):

  while (true)
    gt_total_active += 100ms
    sleep(100ms)


?

If a) then diagram 2) above would show 50% rcs0, no? (When sampled at 
T=0 and T=1s and deltas calculated.)

If b) then "...total active ticks that GT has been active for." uses a 
different definition of "GT active" than I am assuming? Like no relation 
to whether any of the engines is used, just the fact GuC is loaded and 
running?

Regards,

Tvrtko

> 
> Regards,
> Umesh
> 
>>
>> Regards,
>>
>> Tvrtko
>>
>>>
>>> Regards,
>>> Umesh
>>>
>>>>
>>>>>> 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