lkml.org 
[lkml]   [2011]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering

* Steven Rostedt <rostedt@goodmis.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
> progress.
>
> 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
diffstat:

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
unified.

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.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-02-15 19:45    [W:0.090 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site