[Intel-gfx] [RFC 0/3] Engine utilization tracking

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Tue May 9 15:51:05 UTC 2017


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 at 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.

Regards,

Tvrtko


More information about the Intel-gfx mailing list