Messages in this thread | | | Date | Tue, 15 Feb 2011 19:42:00 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |