[Intel-gfx] [RFC 6/6] drm/i915/pmu: Add running counter

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Fri Jan 19 13:48:03 UTC 2018


On 19/01/2018 13:40, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-01-19 11:45:24)
>>
>> On 18/01/2018 11:57, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-01-18 10:41:36)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>
>>>> We add a PMU counter to expose the number of requests currently executing
>>>> on the GPU.
>>>>
>>>> This is useful to analyze the overall load of the system.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>
>>> Ok, the split between queued (unmet dependencies),
>>> submitted (met dependencies, ready for hw) and running (on hw) look good
>>> to me. The usual slight inaccuracies that may arise due to trying to
>>> sample across async hw + engines, but those should be minor. And the
>>> counters seem very useful (at least for the trivial overlay).
>>
>> Glad to hear positive feedback!
>>
>>> The only suggestion I would make is perhaps
>>>
>>>        engine->stats.unready_requests / requests_queued;
>>>        engine->stats.requests_ready / requests_submitted;
>>>
>>> (doesn't have to be stats, but I think we want a bit more verbosity
>>> here).
>>
>> Hm, what is that? You are suggesting some relative stats? Exposed as
>> another counter? It can be calculated in userspace easily.
> 
> Just trying to think of better names than engine->queued.
> I like 'stats' as it says "this is not part of the normal engine
> management, but some auxiliary information we tracked for user
> convenience"; then I was just trying to think of a more apropos name
> than 'queued'. I definitely think we want to let the reader know what's
> queued :)

Oh right, a container definitely makes sense. More verbose naming can do 
as well.

Regards,

Tvrtko


More information about the Intel-gfx mailing list