[Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig

[Joonas Lahtinen]

+ Adding Linus, Dave and Daniel
(because by my knowledge, we're beating a dead horse here)

Quoting Steven Rostedt (2018-12-18 04:14:17)
> On Mon, 17 Dec 2018 18:26:03 -0700
> Michael Sartain <mikesart at fastmail.com> wrote:
> 
> > Ftrace and perf are fantastic, stable, very well known, and documented with
> > ecosystems built around them. AMD already is doing exactly what we are asking
> > for with tracepoints, and Intel has tracepoints that work right now. Please,
> > there must be a way we can enable those and use the current tracing systems
> > without it introducing a stable tracepoint uABI which promises it'll never
> > change until the end of days?
> 
> Would it be helpful if we implemented a way that trace events would not
> show up in the tracefs filesystem unless a specifc kernel command line
> (or module) parameter was supplied?
> 
> That would make for trace events not to be visible by default, but
> allow for the same kernel to make them visible with a simple reboot (or
> module reload). Like adding an option: i915_debug_tracepoints ?
> 
> Or perhaps a sysrq switch?

This wouldn't really change much for the user, would it? After they
update their kernel, the application from their distro that worked
yesterday for their profiling needs, stops working. Kernel parameters
are really not that hard to add. We're today seeing from bug reports
existing debug-only module parameters in daily use causing trouble,
so that we're heavily reducing them already.

Those exact tracepoints are not enabled by default because we've
specifically made an assesment that we'll have hard time maintaining
their delivery in the future with all the changes in our pipeline, even
for the existing platforms. So once you update to a kernel with more
advanced i915 request scheduling, you can wave a goodbye to those.

I'm bit unsure how this situation would be any different from what is
described here by Linus:

https://lkml.org/lkml/2016/11/25/733

If we add new tracepoints that are much closer to the real hardware
events (and thus, less of implementation detail of today), going
forward we'd need to be able to insert trace entries that were captured
by hardware.

The hacky way of doing this is to have the kernel emit tracepoints
from the hardware feed, where the timestamp is an argument. But that
already feels like we've gone beyond what tracepoints were intended
for, and reduced the usefulness of the existing tools.

That combined with the stall of versioning discussion for tracepoints
has kind of got me thinking that a more special purpose uAPI is
needed to solve this elegantly in reasonable time.

But if the tables have turned and we foresee a path forwards solving
the above mentioned issues with tracepoints, I'm happy to hear that
too.

Regards, Joonas

> -- Steve
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx