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

[Ingo Molnar <mingo@elte.hu>]

* Martin Bligh <mbligh@mbligh.org> wrote:

> an external patch is, indeed, pretty useless. Merging a few simple 
> tracepoints should not be a problem [...]

the problem is, LTT is not about a 'few' tracepoints: it adds a whopping 
350 tracepoints, a fair portion of it is multi-line with tons of 
arguments.

 $ diffstat patch-2.6.17-lttng-0.5.108-instrumentation*
 98 files changed, 1450 insertions(+), 64 deletions(-)

saying "it's just a few lightweight tracepoints" misses two points: it's 
not just a few, and it's not lightweight.

and the set of tracepoints never gets smaller. People who start to rely 
on a tracepoint will scream bloody murder if it goes away or breaks. 
Static tracepoints are a maintainance PITA that will rarely get smaller, 
and will easily grow ...

> [...] - see blktrace and schedstats, for instance.

yes, i do want to remove the 34 schedstats tracepoints too, once a 
feasible alternative is present. I already have to do two compilations 
when changing something substantial in the scheduler - once with and 
once without schedstats.

same for blktrace: once SystemTap can provide a compatible replacement, 
it should.

> It amuses me that we're so opposed to external patches to the tree 
> (for perfectly understandable reasons), but we somehow think 
> tracepoints are magically different and should be maintained out of 
> tree somehow.

i think you misunderstood what i meant. SystemTap should very much be 
integrated into the kernel proper, but i dont think the _rules_ (and 
scripts) should become part of the _source code files themselves_. So 
yes, there's advantage to kernel integration, but there's disadvantage 
to littering the kernel source with countless static tracepoints, if 
dynamic tracepoints can offer the same benefits (or more).

the question is: what is more maintainance, hundreds of static 
tracepoints (with long parameter lists) all around the (core) kernel, or 
hundreds of detached dynamic rules that need an update every now and 
then? [but of which most would still be usable even if some of them 
"broke"] To me the answer is clear: having hundreds of tracepoints 
_within_ the source code is higher cost. But please prove me wrong :-)

	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/