From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Theodore Tso <tytso@mit.edu>,
Arjan van de Ven <arjan@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lin Ming <ming.m.lin@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem
Date: Wed, 17 Nov 2010 16:03:32 +0100 [thread overview]
Message-ID: <20101117150332.GA7603@elte.hu> (raw)
In-Reply-To: <1289996753.30543.35.camel@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Are these events now going to be labeled as stable? Is every tracepoint we have,
> much have the same data? Linus specifically said at Kernel Summit that he wants
> absolutely NO modules to have a stable tracepoint.
I think you are worrying about the wrong things.
I think Arjan's complaints at the KS stemmed from prior sporadic declarations on
lkml that there is no tracepoint ABI _at all_, and that powertop/latencytop could
break anytime.
But in reality i strongly disagree with such declarations, and tracepoint data that
is used by PowerTop/timechart/latencytop or perf is and was an ABI, simple as that -
and i've been enforcing that for two years. (We have so few good instrumentation
tools that we _really_ dont want to break them.)
At that point, realizing that we have an ABI for existing tools, i think it's
fundamentally misguided to go out on a limb trying to put barriers in the way of
other tools that do not even exist to begin with ...
Our real problem with tracing is lack of relevance, lack of utility, lack of
punch-through analytical power.
Trying to create a sandbox to _reduce utility_ is like the last step, and a really
optional step, when we have such variety that we want some control over it. It's
always expensive, it always reduces the tool space as collateral damage.
So please dont think of sysfs or eventfs as a tool to restrict. Think of it as a
tool to _organize_.
Again, i'd _LOVE_ to have the 'problem' of us having so many tools that analyze
application and kernel behavior in such a rich way that they use tracepoints that
were not supposed to be 'stable'.
I simply dont see the 'problem' that is being solved here. We had a stable ABI and
we didnt break sysprof or powertop/latencytop in the past and wont break it in the
future either.
Thanks,
Ingo
next prev parent reply other threads:[~2010-11-17 15:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 0:53 [RFC][PATCH 0/5] tracing/events: stable tracepoints Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem Steven Rostedt
2010-11-17 3:32 ` Greg KH
2010-11-17 10:39 ` Ingo Molnar
2010-11-17 12:25 ` Steven Rostedt
2010-11-17 15:03 ` Ingo Molnar [this message]
2010-11-17 15:16 ` Peter Zijlstra
2010-11-17 15:16 ` Steven Rostedt
2010-11-17 15:35 ` Peter Zijlstra
2010-11-17 18:42 ` Ted Ts'o
2010-11-17 15:16 ` Peter Zijlstra
2010-11-23 21:29 ` Steven Rostedt
2010-11-17 17:46 ` Mathieu Desnoyers
2010-11-17 17:52 ` Steven Rostedt
2010-11-17 18:12 ` Mathieu Desnoyers
2010-11-18 9:42 ` Avi Kivity
2010-11-17 23:48 ` Ted Ts'o
2010-11-18 13:05 ` Mathieu Desnoyers
2010-11-17 12:16 ` Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 2/5] [PATCH 2/5] tracing/events: Add code to (un)register stable events Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 3/5] [PATCH 3/5] tracing/events: Add infrastructure to show stable event formats Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 4/5] [PATCH 4/5] tracing/events: Add stable event sched_switch Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 5/5] [PATCH 5/5] tracing/events: Add sched_migrate_task stable event Steven Rostedt
2010-11-17 20:14 ` [RFC][PATCH 0/5] tracing/events: stable tracepoints Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101117150332.GA7603@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=ming.m.lin@intel.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).