Date:	Sat, 16 Sep 2006 02:31:19 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Hi,

On Sat, 16 Sep 2006, Ingo Molnar wrote:

> > As I said before you're mixing up function tracing with event tracing, 
> > not all events are tied to functions, functions can be moved and 
> > renamed, the actual event more often stays the same.
> 
> you are showing a clear misunderstanding of how tracing is typically 
> done.

Not really, you're missing the point I'm trying to make, we want to trace 
_events_ not functions. Function specific tracing would still require 
kernel specific mapping to map function names to events.

> Both for LTT and for blktrace (and for the tracers i've done 
> myself), roughly half (50%) of the tracepoints are right at the top of 
> the function and trace the function arguments. Let me quote an example 
> straight from LTT:
> 
>  int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>  {
>          struct kiocb iocb;
>          struct sock_iocb siocb;
>          int ret;
> 
>          trace_socket_sendmsg(sock, sock->sk->sk_family,
>                  sock->sk->sk_type,
>                  sock->sk->sk_protocol,
>                  size);
> 
> this tracepoint, under a dynamic tracing concept, can be replaced with:
> 
>  int __trace sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>  {
>          struct kiocb iocb;
>          struct sock_iocb siocb;
>          int ret;
> 
> note the "__trace" attribute to the function. (see my previous mails 
> where i talked about __trace for more details) SystemTap can hook to 
> that point and can access the very same parameters that the markup does, 
> in a lot less invasive way.
> 
> So a 5-line markup can be replaced with a single function attribute.

A nice example where you make life more difficult for static tracers for 
no reason, whereas a "trace_socket_sendmsg(sock, size);" is just as 
usable. It would also add virtually no maintainance overhead as you like 
to claim - how often does this function change?

> > Function attributes also doesn't provide information local to the 
> > function.
> 
> of course, but where does the above tracepoint i quoted use information 
> local to the function? A fair number of markups use global functions 
> because, surprise, alot of interesting activity happens along global 
> functions. So a healthy reduction in markups can be achieved.

But not completely, which is the whole point.

> > It's possible I missed something, but pretty much anything you 
> > outlined wouldn't make the live of static tracepoints any easier.
> 
> sorry, but if you re-read the above line of argument, your sentence 
> appears non-sequitor. I said "the markers needed for dynamic tracing are 
> different from the LTT static tracepoints". You asked why they are so 
> different, and i replied that i already outlined what the right API 
> would be in my opinion to do markups, but that API is different from 
> what LTT is offering now. To which you are now replying: "pretty much 
> anything you outlined wouldn't make the life of static tracepoints any 
> easier." Huh?

Yeah, huh?
I have no idea, what you're trying to tell me. As you demonstrated above 
your "right API" is barely usable for static tracers.

> > So if dynamic tracing is available use it, as distributions already 
> > do. OTOH the barrier to use static tracing is drastically different 
> > whether the user has to deal with external patches or whether it's a 
> > simple kernel option. Again, static tracing doesn't exclude the 
> > possibility of dynamic tracing, that's something you constantly omit 
> > and thus make it sound like both options were mutually exlusive.
> 
> how does this reply to my point that: "a marker for dynamic tracing has 
> lower performance impact than a static tracepoint, on systems that are 
> not being traced", which point you claimed moot?

Because it's pretty much an implementation issue. The point is about 
adding markers at all, it's about the choice being able to use static 
tracers in the first place. Both have undeniable their advantages/ 
disadvantages, where you prefer to emphasize only the strong points of 
dynamic tracing and constantly declare its problems as nonissues.

> > > Secondly, even people who intend to _eventually_ make use of 
> > > tracing, dont use it most of the time. So why should they have more 
> > > overhead when they are not tracing? Again: the point is not moot 
> > > because even though the user intends to use tracing, but does not 
> > > always want to trace.
> > 
> > I've used kernels which included static tracing and the perfomance 
> > overhead is negligible for occasional use.
> 
> how does this suddenly make my point, that "a marker for dynamic tracing 
> has lower performance impact than a static tracepoint, on systems that 
> are not being traced", "moot"?

Why exactly is the point relevant in first place? How exactly is the added 
(minor!) overhead such a fundamental problem?

> > Why don't you leave the choice to the users? Why do you constantly 
> > make it an exclusive choice? [...]
> 
> as i outlined it tons of times before: once we add markups for static 
> tracers, we cannot remove them. That is a constant kernel maintainance 
> drag that i feel uncomfortable about.

As many, many people have already said, any tracepoints have an 
maintainance overhead, which is barely different between dynamic and 
static tracing and only increases the further away the tracepoints are 
from the source.

bye, Roman
-
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