Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108


* Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote:

Hi,

On Fri, 15 Sep 2006, Ingo Molnar wrote:

What Karim is sharing with us here (yet again) is the real in-field
experience of real users (ie: not kernel developers).

well, Jes has that experience and Thomas too.

I mean, on one hand we have people explaining what they think a
tracing facility should and shouldn't do, and on the other hand we
have a guy who has been maintaining and shipping exactly that thing to
(paying!) customers for many years.

so does Thomas and Jes. So what's the point?

That only Karim's experience is being in question here?

i think you misunderstood, please read the paragraphs above. They
suggest that there's "real in-field experience of real users" against
"people explaining what they think a tracing facility should and
shouldn't do". I only pointed out that those people (Thomas, Jes) dont
just randomly express their opinion but have actual in-field experience
too (of paying customers), about the very topic at hand.

i judge LTT by its current code quality, not by its proponents shouting
volume - and that quality is still quite poor at the moment. (and then
there are the conceptual problems too, outlined numerous times) I have
quoted specific example(s) for that in this thread. Furthermore, LTT
does this:

246 files changed, 26207 insertions(+), 71 deletions(-)

and this gives me the shivers, for all the reasons i outlined.

Well, I'm first to admit that LTT needs improvement, but that has
never been the point.

that might not be your point, but that very much is my point. I do claim
that LTT's problems arise out of its fundamental mistake on the kernel
side: that it is a static tracer that tries to be too many things to too
many people. SystemTap is available here and today on an unmodified
upstream kernel. LTT has been in this shape for the past ~8 years. But
if you wish you can certainly prove me wrong via for example cleaning up
and shrinking LTT down to a size and impact that is not scary anymore,
with the same functionality, and the clear future path for the removal
of its dependencies. I tried to argue that in the abstract, but please
by all means feel free to prove me wrong. (or argue against my specific
points)

We need to get to some kind of agreement what level of tracing Linux
should support in general, preferably something that is easy to
integrate and usable by everyone. Especially the latter means that
there is not one true solution, [...]

sorry, but i disagree. There _is_ a solution that is superior in every
aspect: kprobes + SystemTap. (or any other equivalent dynamic tracer)

At this point you've been rather uncompromising [...]

yes, i'm rather uncompromising when i sense attempts to push inferior
concepts into the core kernel _when_ a better concept exists here and
today. Especially if the concept being pushed adds more than 350
tracepoints that expose something to user-space that amounts to a
complex external API, which tracepoints we have little chance of ever
getting rid of under a static tracing concept.

i'm also looking at it this way too: you already seem to be quite
reluctant to add kprobes to your architecture today. How reluctant would
you be tomorrow if you had static tracepoints, which would remove a fair
chunk of incentive to implement kprobes?

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

Relevant Pages

  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... Jes has that experience and Thomas too. ... tracing facility should and shouldn't do, and on the other hand we ... Well, I'm first to admit that LTT needs improvement, but that has never ...
    (Linux-Kernel)
  • Re: 2.6.11-rc1-mm1
    ... LTT isn't meant for kernel ... However, if you are kernel debugging, you will find the ad-hoc mode I'm ... Common Thomas, ...
    (Linux-Kernel)
  • Re: realtime-preempt for MIPS - compile problem with rwsem
    ... perhaps Thomas Gliexner and myself). ... Thomas and I are just the janitors ... constrained in having to use a 2.6.15 kernel ... ... In the more common hangs though, ...
    (Linux-Kernel)
  • Re: virt_to_page/pci_map_page vs. pci_map_single
    ... Jes> Hmmm, my brain has gotten ia64ified;-) It's basically the normal ... Jes> mappings of the kernel, ie. the kernel text/data/bss segments as ... Jes> well as anything you do not get back as a dynamic mapping such as ... David> addresses. ...
    (Linux-Kernel)
  • Re: =?ISO-8859-15?Q?Verschl=FCsselte?= Partition weg
    ... Thomas Bächler wrote: ... No key available with this passphrase. ... Irgendwas ist wohl beim Kernel kompilieren schief gegangen, ... Next by Date: ...
    (de.comp.os.unix.linux.misc)