Message-ID: <20100714204531.GA14474@elte.hu>
Date:	Wed, 14 Jul 2010 22:45:31 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 10/13]  perf: Re-Add make_absolute_path


* Arnaldo Carvalho de Melo <acme@...radead.org> wrote:

> Em Tue, Jul 13, 2010 at 10:49:27PM -0400, Steven Rostedt escreveu:
> > On Mon, 2010-07-12 at 13:12 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Jul 12, 2010 at 10:30:36AM -0400, Steven Rostedt escreveu:
> 
> > > Well, I prefer to follow the kernel way of doing things, i.e. to
> > > propagate as much as possible up the callchain the error return value,
> > > so that the apps can handle it in any way they prefer, i.e. die() calls
> > > in tools/perf/builtin-foo.c are okayish, but not on tools/perf/util/.
> 
> > Ah, yes, die is a bit strong. And I have been starting to avoid them
> > too. Although, when malloc fails, it's almost certain that the app will
> > die soon anyway ;-)
> 
> The interesting thing is that years ago, when modules were being introduced 
> in the kernel and panic() calls for things like out of memory conditions 
> were being removed, some people made the same comments, 'if that happens, 
> you're doomed anyway!' :-)
> 
> I can see things like trying to load a huge perf.data file in the TUI 
> interface failing and the user just being warned about it and going on with 
> life loading some other file, etc.
> 
> Certainly it is interesting to try to apply as much as possible of the 
> mindset (and fear of criticism) present when coding for the kernel when one 
> codes for userland.

Yeah, and especially for perf the absolutely most important quality is 
reliability. It's not just an app - it's a measurement tool. People rely on it 
to reject or apply patches, on a daily basis.

perf must be very reliable and very dependable (and i'm happy that we managed 
to achieve that goal so far :), and if it fails it should be apparent that it 
failed and that results should not be relied on.

With other tools that are statistical i've sometimes seen a special type of 
dangerous attitude of: "hey, it's just a sample, no biggie if it's lost, it's 
just statistical anyway, lost in the noise" - but that's really a slippery 
slope leading to a sloppy tool we cannot depend on 110%.

Just like physicists or engineers want to be able to trust their measurement 
instruments, do we want kernel hackers to be able to trust the results of 
perf.

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