+ 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
