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

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2018-08-22 15:49:52)
> 
> 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.

To clarify, I meant to underline that there is not going to be a steep
switching point where a transition from interface A to B, which Svetlana
referred to, would happen naturally.

The introduced interface will have to provide the information for years
and kernel versions to come, and we already have a some data that
tracepoints may not be the format of choice due to GuC.

> 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.

Yes, for tools that depend on the tracepoints. That's why it is most
likely best to introduce the information in some other form, but I am
starting to sound like a broken record already :)

Regards, Joonas

> 
> Regards,
> 
> Tvrtko