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
