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

"Karim" == Karim Yaghmour <karim@xxxxxxxxxxx> writes:

Karim> Ingo Molnar wrote:
that's not true, and this is the important thing that i believe you
are missing. A dynamic tracepoint is _detached_ from the normal
source code and thus is zero maintainance overhead. You dont have
to maintain it during normal development - only if you need it. You
dont see the dynamic tracepoints in the source code.

Karim> And that's actually a problem for those who maintain such
Karim> dynamic trace points.

And who should pay here? The people who want the tracepoints or the
people who are not interested in them?

a static tracepoint, once it's in the mainline kernel, is a nonzero
maintainance overhead _until eternity_. It is a constant visual
hindrance and a constant build-correctness and boot-correctness
problem if you happen to change the code that is being traced by a
static tracepoint. Again, I am talking out of actual experience
with static tracepoints: i frequently break my kernel via static
tracepoints and i have constant maintainance cost from them. So
what i do is that i try to minimize the number of static
tracepoints to _zero_. I.e. i only add them when i need them for a
given bug.

Karim> Bzzt, wrong. This is your own personal experience with
Karim> tracing. Marked up code does not need to be active under all
Karim> build conditions. In fact trace points can be inactive by
Karim> default at all times, except when you choose to build them in.

You have obviously never tried to maintain a codebase for a long
time. Even if the code is not activated, you make a change and
something breaks and people come running and screaming, or the thing
is in the way for the structural code change you want to make.

Not to mention that some of the classical places people wish to add
those static tracepoints are in performance sensitive codepaths,
syscalls for example.

static tracepoints are inferior to dynamic tracepoints in almost
every way.

Karim> Sorry, orthogonal is the word.

You can do pretty much everything you want to do with dynamic
tracepoints, it's just a matter of whether you want to dump the burden
of maintenance on someone else. Been there done that, had to show
people in the past how to do with dynamic points what they insisted
had to be done with static points.

hundreds (or possibly thousands) of tracepoints? Have you ever
tried to maintain that? I have and it's a nightmare.

Karim> I have, and I've showed you that you're wrong. The only reason
Karim> you can make this argument is that you view these things from
Karim> the point of view of what use they are for you as a kernel
Karim> developer and I will repeat what I've said for years now:
Karim> static instrumentation of the kernel isn't meant to be useful
Karim> for kernel developers.

So you maintain the tracepoints in the kernel and you are offering to
take over maintenance of all code that now contain these tracepoints?
You add your static tracepoints, next week someone else wants some
very similar but slightly different points, the following week it's
someone else. Thanks, but no thanks.

Karim> Nevertheless there are
Karim> very legitimate uses for standardized instrumentation points.

Some evidence would be useful here, so far you haven't provided any.

Jes
-
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
    ... tracepoints irrelevant since you are turning all the tracepoints into ... How many embedded Linux projects did you personally work on? ... I did apologize to Karim for the mistake i ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... kernel infrastructure. ... Tracepoints of course need to be managed, ... and thus is zero maintainance overhead. ... i frequently break my kernel via static tracepoints and i ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... People want to be able to insert a tracepoint anywhere and anytime - and also they want to have zero overhead from tracing if no tracepoints are used on a system. ... on the current kernel, because the 'coupling' is loose: ... you can add add-hoc tracepoints to thousands of functions, instead of having to maintain hundreds of static tracepoints all the time. ... are magically different and should be maintained out of tree somehow. ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... source-intrusive method of adding tracepoints instead of the dynamic, ... kernel codepath that is to be traced, ... have less overhead when it's actually used. ... static tracepoints are fundamentally limited: ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... If they already have to go with their own tracepoints for the ... Dynamic instrumentation fills the same sort of gap ... for not having to depend on me to get a working traceable kernel. ... The static tracepoints we maintained were *the* solution for a great ...
    (Linux-Kernel)