[Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Wed Aug 22 12:49:52 UTC 2018


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


More information about the Intel-gfx mailing list