[Intel-gfx] [PATCH 7/8] drm/i915/pmu: Wire up engine busy stats to PMU
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Sep 27 08:10:55 UTC 2017
On 26/09/2017 21:05, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-09-26 13:32:25)
>>
>> On 25/09/2017 18:48, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2017-09-25 16:15:42)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>
>>>> We can use engine busy stats instead of the MMIO sampling timer
>>>> for better efficiency.
>>>>
>>>> As minimum this saves period * num_engines / sec mmio reads,
>>>> and in a better case, when only engine busy samplers are active,
>>>> it enables us to not kick off the sampling timer at all.
>>>
>>> Or you could inspect port_isset(execlists.port).
>>> You can avoid the mmio for this case also by just using HWSP. It's just
>>> that I never enabled busy tracking in isolation, so I always ended up
>>> using the mmio.
>>
>> This would be for execlists only. I could change the main patch to do
>> this, you think it is worth it?
>
> I'm thinking we do the busy = last_seqno != current_seqno approach for
> the first patch. Then this patch is purely about the accuracy
> improvement for execlists, taking advantage of the existing interrupts.
Was just saying, ok, either port_isset or last_seqno != current_seqno.
And then for queued, I was thinking to change it from time to count.
That would give queue depth to userspace which is an interesting metric
to build any balancing on top of.
I did a quick experiment yesterday and even queue depth expressed as the
flawed last_seqno - current_seqno is potentially showing a small but
consistent improvement against pure busyness based balancing (load =
busy * qd). So I am curious how it would look with a more correct queue
depth metric.
> We could do something similar by forcing the user interrupt and treating
> that as context-out, likely to be much more fiddly than execlists and
> those processors did not take kindly to a flood of interrupts from the
> gpu. (Or that may just be a side-effect of the interrupt handler from a
> few years ago.)
For ringbuff? I think not so interesting.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list