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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 22/08/2018 13:49, Tvrtko Ursulin wrote:
> 
> 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.

P.S. To clarify - which is exactly why we marked those tracpoints as low 
level and why it is problematic to rely on them.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx