|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Steven Rostedt <rostedt-AT-goodmis.org> |
|| ||Re: Fix powerTOP regression with 2.6.39-rc5 |
|| ||Sat, 7 May 2011 16:44:02 +0200|
|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>,
Arjan van de Ven <arjan-AT-linux.intel.com>,
Frederic Weisbecker <fweisbec-AT-gmail.com>,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Thomas Gleixner <tglx-AT-linutronix.de>|
|| ||Article, Thread
* Steven Rostedt <firstname.lastname@example.org> wrote:
> 2) we separate perf from ftrace and keep the "stable" ABI for perf, and let
> ftrace advance into a more efficient tracer.
The thing is, ftrace is still largely separated from perf, and this is why this
regression came in: a random tracing 'cleanup' churn was done to 'tracing'
which broke PowerTop.
Look at the commit itself:
e6e1e2593592: tracing: Remove lock_depth from event entry
Clearly you didnt even *realize* that there's a whole tooling world behind this
The core perf ABI is set up in a way that makes it rather hard to break the ABI
accidentally. I can bisect back kernel release after kernel release and old
tooling will work on new kernel and new tooling will work on old kernels.
PowerTop uses the perf ABI because it's a rather convenient and unified method
to get a rich selection of events via the same facility, same ring-buffer,
using a system call ABI, etc.
The ftrace event bits on the other hand, still somewhat glued on to the perf
ABI are still very fragile to such spurious changes like the one that caused
the regression here.
I raised this issue in the past. ftrace and perf has to be unified sooner
rather than later.
> Here's the choices then:
> 1) we get libparsevent.so out into the world and all tools can use it, and
> the raw formats of the trace events will no longer be an issue as long as the
> names of events and fields stay the same.
Firstly, such an event parser already exists in
tools/perf/util/parse-events.[ch], so if you want to librarize it please talk
to Arnaldo to create tools/perf/lib/ and a libperf.so.
There's 10 separate contributors to that file already:
earth4:~/tip> git-authors-email tools/perf/util/parse-events.c
2 Peter Zijlstra <email@example.com>
2 Stephane Eranian <firstname.lastname@example.org>
2 Ulrich Drepper <email@example.com>
3 Jason Baron <firstname.lastname@example.org>
3 Li Zefan <email@example.com>
3 Peter Zijlstra <firstname.lastname@example.org>
7 Frederic Weisbecker <email@example.com>
7 Jaswinder Singh Rajput <firstname.lastname@example.org>
13 Arnaldo Carvalho de Melo <email@example.com>
15 Ingo Molnar <firstname.lastname@example.org>
Most notably *you* are not amongst them. Not a single commit out of close to a
hundred commits. Why not? This really demonstrates the level of disinterest you
are showing towards perf based tooling, still you keep modifying the underlying
code in the kernel.
Secondly, you are solving the wrong problem and you are not seeing the real
problems. We can keep and we *will* keep ABIs, it's not hard. 4 bytes padding
is not an issue and it never was for PowerTop nor for any other real person who
relies on tracing.
As i see it the problem is the thought-less ftrace churn and the fragility of
how TRACE_EVENT() can be changed.
Really, ftrace and in particular you are showing a huge disconnect and i'm
increasingly unhappy about it. Look at this very thread: you fought tooth and
nail to even *acknowledge* that there is a problem...
As things look like from my side it appears you want to keep ftrace a messy,
forked project with no regard to perf based tooling and this will fragment
Linux instrumentation, the many technical disadvantages be damned.
I simply do not see that you understand this whole problem space, i do not see
that you are driving towards unifying ftrace and perf - i only see that you are
hacking in random, sometimes harmful directions and that you are stubornly
ignoring my negative feedback about this. If problems like this continue i will
have to stop pulling new ftrace features from you.
to post comments)