Re: [PATCH 7/8] drm/i915/pmu: Wire up engine busy stats to PMU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxx>

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux