Date:	Tue, 15 Feb 2011 19:42:00 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust
 filtering


* Steven Rostedt <rostedt@...dmis.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists