Re: [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

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

 




On 21/08/2018 13:06, Joonas Lahtinen wrote:
Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
Joonas, sorry for interfering; could you please explain more regarding the
options for tracing scheduling events better than tracepoints?
After scheduling moves to GuC tools will have to switch to something like
GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution?
I know gpuvis is not the only attempt to use tracepoints for the same purpose.
(there're trace.pl and S.E.A. and of course VTune though it probably is not
considered to be existing as it's not open source).
And assuming this movement towards GuC is it not too late to invent a
completely new way to provide tools with scheduling info from kmd?
Could we just improve the existing way and let it live its last years\months?

Hi,

You actually mentioned the prime reason why we should not go and
hastily make tracepoints a stable uAPI with regards to scheduling
information.

The scheduler's nature will be evolving when some of the scheduling
decisions are moved to GuC and the way how we get the information
will be changing at that point, so tracepoints will indeed be a
very bad mechanism for providing the information.

The kernel scheduler is definitely not going anywhere with the
introduction of more hardware scheduling capabilities, so it is a
misconception to think that the interface would need to be completely
different for when GuC is enabled.

On the last paragraph - even with the today's GuC i915 already loses visibility of CSB interrupts. So there is already a big difference in semantics of what request_in and request_out tracepoints mean. Put preemption into the picture and we just don't know any more when something started executing on the GPU, when it got preempted, re-submitted etc. So I think it is fair to say that moving more of scheduling into the GuC creates a problem for tools which want to represent request execution timelines.

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