* Ingo Molnar (mingo@xxxxxxx) wrote: > > * Greg KH <greg@xxxxxxxxx> wrote: > > > On Thu, Dec 08, 2011 at 06:23:54AM +0100, Ingo Molnar wrote: [...] > > > There's a highly constructive, open attitude towards LTTNG and > > > has been for years: > > > > > > " Mathieu, please split it up and integrate/unify it with the > > > existing instrumentation features of Linux - and if it > > > replaces existing stuff because an LTTNG component is > > > superior then so be it. " > > > > Ok, that's fair enough. > > > > Mathieu, will you please work on this? Or is there some > > reason you don't feel this is possible? > > Mathieu, any update on this? I don't want the LTTNG goodies to > drop on the floor - we just have to integrate them properly. > > If you 100% disagree with how specific things are done upstream > right now then don't hold back: just replace existing mechanisms > - that gives a starting point to discuss what the best way is > forward. I'm bringing a though question then: what should we do if I strongly think that the current ABIs should be replaced ? To support this, let's note that the current perf ABI: - lacks versioning information to handle change. I think shipping the tracer tools within the Linux tools/ directory made sense for an initial phase that made tracer solutions more popular for kernel developers (and it did a great job a that), but if we want to move on to build tools that target a wider audience, we should leave the tools/ sandbox and create separate projects, with clearly defined ABIs, using ABI versioning to manage changes. At this point, I think that perf tool shipped within tools/ is more than anything a pain for non-kernel-developer users, and favors design of sloppy ABIs. - makes it impossible to move to CTF (Common Trace Format) and benefit from the added features it allows, - makes it needlessly hard, if not impossible, for perf to move to something that would have the benefits brought by the fast unified ring buffer code I created 2 years ago, - makes it impossible to benefit from the LTTng fast trace clocks. Also, it should be noted that I am finding that the way perf evolved into a large monolithic binary blob that needs to be all enabled or all disabled makes it quite hard to extend and re-use. As a matter of fact, there are various cases where Steven and I tried to create performance tests for the perf ring buffer and just could not do it without hacking the perf code. I would definitely prefer to go for a modular approach for the in-kernel code, and an approach based on user-level libraries for low-level tracer interaction, with applications depending on those libraries, again all handled with ABI versioning and library versioning. I have to give recognition to perf: it's a fantastic performance counter management/sampling tool, but it has clearly never been geared towards low-overhead tracing, and this shows. One possible way for moving things forward is to leave the current perf/ftrace implementation and ABIs in place along with the existing tools. We could create a new ABI merging perf, ftrace and LTTng best features into one (e.g. kstrace for Kernel System Trace -- just made it up, better ideas are welcome), and gradually move the user-space part of the 3 tools to the new ABI. It is worth noting that the need for a new ABI is something many people involved in tracing -- by that I mean those doing most of the actual upstream tracer implementation work -- agreed upon in the last 2 years when meetings at conferences. This would allow a deprecation phase to take place, and would allow removal of the maintenance burden of the duplicated Perf/Ftrace ABIs, all that while also bringing in an ABI that allows handling of change and innovation, which is, IMHO, the key limiting factor of the current ABIs. By doing so, perf could become the set of tools targeting what it does best: performance counters management and sampling, ftrace could keep on targeting function tracing, and lttng could be used for all-system tracing, everyone sharing the same kernel-level implementation and ABIs (kstrace ABI). Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
