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

[Ingo Molnar]

* Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:

> [...]  It would be much better if we were able to sketch out plausible 
> designs for static instrumentation and similar dynamic probes, and 
> carry out gedanken experiments aobut how they would need to adopt to 
> realistic examples of code drift.  It is not the case that all 
> "maintenance" is alike.

see my previous mail - hopefully that explains my position even clearer.

A number of people have expressed doubts about the all-static model (i'm 
amongst them) - and that's all based on actual experience. So there's no 
need for Gedanken-experiments, because we've got real-life experiments
:-) A number of people also have expressed that they think an all-static
markup model is the right one - and that's based on experience as well.

Just looking at the opinions objectively and excluding my opinion i'd 
say that the most likely model will thus be a _hybrid_ one: some 
markups will be static, some will be dynamic.

Whether a tracepoint will be static or dynamic will depend on the 'flux 
of changes' in the tracing code and of the code they trace. If tracing 
code has a high flux, or the traced code has a high flux, then the 
lowest maintainance overhead is to have a dynamic tracepoint. If _both_ 
the tracing code and the traced code has low flux of changes, then the 
lowest maintainance overhead will be a static markup.

Put differently: dynamic markups will turn into static markups if the 
code that they handle "cools down". Static markups will turn into 
dynamic markups if the code where they reside in gets "too hot" or if 
the markups themselves are "too hot".

But one thing is sure: with a static tracer model accepted into the 
kernel we are forced to have a comprehensive, always-maintained, full 
set of static markups in the tree, for a long time. Dynamic tracers will 
still be around, but we wont be able to fully benefit from the more 
flexible tracepoint maintainance models they allow, because we'll always 
have to carry around the static markups, for the sake of static tracers. 
There will likely be periodic friction about how many static markups 
there should be in the source: subsystem maintainers will want them out, 
static-trace-users will want them in. If a crutial static markup is 
removed or damaged then the kernel will regress materially.

	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/