Re: [RFC 0/3] Engine utilization tracking

[Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>]

On 5/9/2017 8:51 AM, Tvrtko Ursulin wrote:
>
> On 09/05/2017 16:29, Chris Wilson wrote:
>> On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote:
>>>
>>> On 09/05/2017 15:26, Chris Wilson wrote:
>>>> On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:
>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>
>>>>> By popular customer demand here is the prototype for cheap engine 
>>>>> utilization
>>>>> tracking.
>>>>
>>>> customer and debugfs?
>>>
>>> Well I did write in one of the following paragraphs on this topic.
>>> Perhaps I should have put it in procfs. :) Sysfs API looks
>>> restrictive or perhaps I missed a way to get low level (fops) access
>>> to it.
>>>
>>>>> It uses static branches so in the default off case it really 
>>>>> should be cheap.
>>>>
>>>> Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL
>>>
>>> Off case are three no-op instructions in three places in the irq
>>> tasklet. And a little bit of object size growth, if you worry about
>>> that aspect?
>>
>> It's just how the snowball begins.
>
> We should be able to control it. We also have to consider which one is 
> lighter for this particular use case.
>
>>>> which looks to be the same level of detail. I wrapped all this up in a
>>>> perf interface once up a time...
>>>
>>> How does that work? Via periodic sampling? Accuracy sounds like it
>>> would be proportionate to the sampling frequency, no?
>>
>> Right, and the sampling frequency is under user control (via perf) with
>> a default of around 1000, gives a small systematic error when dealing 
>> with %
>>
>> I included power, interrupts, rc6, frequency (and the statistics but I
>> never used those and dropped them once oa landed), as well as
>> utilisation, just for the convenience of having sane interface :)
>
> Can you resurrect those patches? Don't have to rebase and all but I 
> would like to see them at least.
Mind that the idea behind the requested kind of stats is primary usage 
by the customers in the _product_ environment to track GPU occupancy and 
predict based on this stats whether they can execute something else. 
Which means that 1) debugfs and any kind of debug-like infrastructure is 
really a no-option, 2) any kind of restrictions are no-option (like 
disable RC6 states). Also, there is no need to expose low-level detailed 
information like how many EUs and VMEs were in use - this belongs to the 
debug things. As for now i915 driver exposes only single required 
metric: gt_act_freq_mhz.

> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx