LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <email@example.com>
To: Steven Rostedt <firstname.lastname@example.org>
Andrew Morton <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Frederic Weisbecker <email@example.com>,
Mathieu Desnoyers <firstname.lastname@example.org>,
Lai Jiangshan <email@example.com>,
Li Zefan <firstname.lastname@example.org>,
Masami Hiramatsu <email@example.com>,
Tom Zanussi <firstname.lastname@example.org>,
Arnaldo Carvalho de Melo <email@example.com>,
Peter Zijlstra <firstname.lastname@example.org>,
Linus Torvalds <email@example.com>
Subject: Re: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering
Date: Tue, 15 Feb 2011 19:42:00 +0100 [thread overview]
Message-ID: <20110215184200.GA7335@elte.hu> (raw)
* Steven Rostedt <firstname.lastname@example.org> wrote:
> On Tue, 2011-02-15 at 05:44 +0100, Ingo Molnar wrote:
> > So ... i have to say that this tracing filter business is unusable crap from a
> > user POV right now and i see no reason to pull *anything* in this area until it
> > does not get improved to *much* better levels of usability and utility.
> > Nobody could *ever* have tested this with a 'naive but curious user' hat on and
> > this is really sad. We need to do much better!
> Sorry I did not work with perf in writing this code. I was using the debugfs
> directly. I figured that any improvement I made there would also improve perf as I
> tried to make sure the perf hooks into that code were updated too.
> My question is, did this patch set cause any of the perf problems or did these
> problems always exist?
> I'm just saying that perf is not the only user. And to deny improvements in the
> code because one user does not currently work well with them is just hindering
> There happens to be real users out in the world that are still using ftrace. I see
> no reason to stop improving it because your goal is to have everyone move to perf.
> Thanks for letting me waste three days on developing this. I even posted an RFC a
> while back, and no one complained then.
I initially pulled your bits with the intention of merging them, tested them as the
final line of defense, gave you my feedback in my mail in a very detailed way, with
suggestions of what to improve.
A few lines I would normally not worry about, but I refuse to pull such a massive
3 files changed, 754 insertions(+), 170 deletions(-)
That ignores a major usecase. I do not pull bits that are arcane to begin with which
improve something that we don't even know whether it works in all cases - in fact
which we know does not work at all in a major usecase, as my testing has shown.
My point is that you guys need to work this out with the 'other side' *before* it
goes upstream. The tracing and perf code needs to stop doing this kind of
self-serving improvements *when basic utility sucks so much*.
And yes, it sucks both on the perf and the ftrace tracing 'side' - in no small part
because there's two sides.
We had huge churn in the tracing code in the last 2 years and frankly i do not see
the results and i do not see it getting cleaned up and i do not see it getting
I find this kind of 'the other side does not exist' schizm quite harmful to the
'generic' code in question and am pushing back on you, as i'm expected to. I don't
care whether it's "perf's fault" or "ftrace's fault" - i find the whole artificial
division harmful and refuse to elongate/deepen it.
Anyway, there's certainly encouraging responses in this thread so i'm hopeful that
it's getting fixed and improved and we can push the generic bits upstream.
next prev parent reply other threads:[~2011-02-15 18:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 1:56 Steven Rostedt
2011-02-08 1:56 ` [PATCH 01/14] tracing/filter: Have no filter return a match Steven Rostedt
2011-02-08 1:56 ` [PATCH 02/14] tracing/filter: Move OR and AND logic out of fn() method Steven Rostedt
2011-02-08 1:56 ` [PATCH 03/14] tracing/filter: Dynamically allocate preds Steven Rostedt
2011-02-08 1:56 ` [PATCH 04/14] tracing/filter: Call synchronize_sched() just once for system filters Steven Rostedt
2011-02-08 1:56 ` [PATCH 05/14] tracing/filter: Allocate the preds in an array Steven Rostedt
2011-02-08 1:56 ` [PATCH 06/14] tracing/filter: Free pred array on disabling of filter Steven Rostedt
2011-02-08 1:56 ` [PATCH 07/14] tracing/filter: Use a tree instead of stack for filter_match_preds() Steven Rostedt
2011-02-08 1:56 ` [PATCH 08/14] tracing/filter: Optimize short ciruit check Steven Rostedt
2011-02-08 1:56 ` [PATCH 09/14] tracing/filter: Check the created pred tree Steven Rostedt
2011-02-08 1:56 ` [PATCH 10/14] tracing/filter: Optimize filter by folding the tree Steven Rostedt
2011-02-08 1:56 ` [PATCH 11/14] tracing/filter: Move MAX_FILTER_PRED to local tracing directory Steven Rostedt
2011-02-08 1:56 ` [PATCH 12/14] tracing/filter: Increase the max preds to 2^14 Steven Rostedt
2011-02-08 1:56 ` [PATCH 13/14] tracing/filter: Swap entire filter of events Steven Rostedt
2011-02-08 1:56 ` [PATCH 14/14] tracing/filter: Remove synchronize_sched() from __alloc_preds() Steven Rostedt
2011-02-15 4:44 ` [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering Ingo Molnar
2011-02-15 13:33 ` Steven Rostedt
2011-02-15 16:29 ` Steven Rostedt
2011-02-15 16:53 ` Frederic Weisbecker
2011-02-15 18:35 ` Arnaldo Carvalho de Melo
2011-02-16 13:34 ` Masami Hiramatsu
2011-02-16 14:52 ` Arnaldo Carvalho de Melo
2011-02-15 18:42 ` Ingo Molnar [this message]
2011-02-15 18:59 ` Steven Rostedt
2011-02-16 9:10 ` Ingo Molnar
2011-02-15 13:44 ` Arnaldo Carvalho de Melo
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).