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

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-26 11:46:51)
> 
> On 25/06/2018 21:02, Chris Wilson wrote:
> > If we know what is wanted can we define that better in terms of
> > dma_fence and leave lowlevel for debugging (or think of how we achieve
> > the same with generic bpf? kprobes)? Hmm, I wonder how far we can push
> > that.
> 
> What is wanted is for instance take trace.pl on any kernel anywhere and 
> it is able to deduce/draw the exact metrics/timeline of command 
> submission for an workload.
> 
> At the moment it without low level tracepoints, and without the 
> intel_engine_notify tweak, it is workload dependent on how close it 
> could get.

Interjecting what dma-fence already has (or we could use), not sure how
well userspace can actually map it to their timelines.
> 
> So a set of tracepoints to allow drawing the timeline:
> 
> 1. request_queue (or _add)
dma_fence_init

> 2. request_submit

> 3. intel_engine_notify
For obvious reasons, no match in dma_fence.

> 4. request_in
dma_fence_emit

> 5. request out
dma_fence_signal (similar, not quite, we would have to force irq
signaling).
 
> With this set the above is possible and we don't need a lot of work to 
> get there.

From a brief glance we are missing a dma_fence_queue for request_submit
replacement.

So next question is what information do we get from our tracepoints (or
more precisely do you use) that we lack in dma_fence?

> And with the Virtual Engine it will become more interesting to have 
> this. So if we had a bug report saying load balancing is not working 
> well, we could just say "please run it via trace.pl --trace and attach 
> perf script output". That way we could easily see whether or not is is a 
> problem in userspace behaviour or else.

And there I was wanting a script to capture the workload so that we
could replay it and dissect it. :-p
-Chris