lkml.org 
[lkml]   [2006]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tracepoint maintainance models

Hi,

* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > Karim, i dont usually reply if you insult me (and you've grown a habit
> > of that lately ), but this one is almost parodic. To understand my
> > point, please consider this simple example of a static in-source markup,
> > to be used by a dynamic tracer:
> >
> > static int x;
> >
> > void func(int a)
> > {
> > ...
> > MARK(event, a);
> > ...
> > }
> >
> > if a dynamic tracer installs a probe into that MARK() spot, it will have
> > access to 'a', but it can also have access to 'x'. While a static
> > in-source markup for _static tracers_, if it also wanted to have the 'x'
> > information, would also have to add 'x' as a parameter:
> >
> > MARK(event, a, x);
> >
>
> Hi,
>
> If I may, if nothing marks the interest of the tracer in the "x"
> variable, what happens when a kernel guru changes it for y (because it
> looks a lot better). The code will not compile anymore when the markup
> marks the interest for x, when your "dynamic tracer" markup will
> simply fail to find the information. My point is that the markup of
> the interesting variables should follow code changes, otherwise it
> will have to be constantly updated elsewhere (hmm ? Documentation/
> someone ?)

yeah - but it shows (as you have now recognized it too) that even static
markup for dynamic tracers _can_ be fundamentally different, just
because dynamic tracers have access to information that static tracers
dont.

(Karim still disputes it, and he is still wrong.)

> I would say that not marking a static variable just because it is less
> visually intrusive is a not such a good thing to do. That's not
> because we *can* that we *should*.

yeah. But obviously the (small but present) performance advantage is
there too, so it shouldnt be rejected out of hand. If a parameter is not
mentioned then it does not have to be prepared for function paramter
passing, etc. So it's 1-2 instructions less. So if this is in some
really stable area of code then it's a valid optimization.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-18 05:33    [W:0.348 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site