lkml.org 
[lkml]   [2010]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv9 2.6.35-rc4-tip 10/13] perf: Re-Add make_absolute_path
* Ingo Molnar (mingo@elte.hu) wrote:
>
> * Arnaldo Carvalho de Melo <acme@infradead.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.

I'm glad to see we're on the exact same page here. :)

Having reliable trace analysis tools is crucially important for both kernel
developers and end-users, especially when, as an example, someone try to use the
results to find out which is the "one" odd-case longest/shortest interrupt
handler during a day-long trace while trying to pinpoint a bug.

Thanks,

Mathieu

>
> Thanks,
>
> Ingo

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com


\
 
 \ /
  Last update: 2010-07-14 22:53    [W:0.040 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site