[lttng-dev] [PATCH 09/11] sched: export task_prio to GPL modules

[Mathieu Desnoyers]

* Ingo Molnar (mingo at elte.hu) wrote:
> 
> * Greg KH <greg at kroah.com> 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