Date:	Sun, 17 Sep 2006 11:36:33 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Karim Yaghmour <karim@...rsys.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>, Jes Sorensen <jes@....com>,
	Andrew Morton <akpm@...l.org>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: tracepoint maintainance models

Hi,

* Ingo Molnar (mingo@...e.hu) wrote:
>   - model #2: we could have the least intrusive markers in the main
>     kernel source, while the more intrusive ones would still be in the
>     upstream kernel, but in scripts/instrumentation/.
> 

Please define : marker intrusiveness. I think that this is not a sole concept.
First, I think we have to look at intrusiveness under three different angles :

- Visual intrusiveness (hurts visually in the code)
- Compiled-in, but inactive intrusiveness
  - Modifies compiler optimisations when the marker is compiled in but no
    tracing is active.
  - Wastes a few cycles because it adds NOPs, jump, etc in a critical path
    when tracing is not active.
- Active tracing intrusiveness
  - Wastes too many cycles in a critical path when tracing is active.

The problem is that a static marker will speed up the active tracing while a
dynamic probe will speed up the case where tracing is inactive. The problem is
that the dynamic probe cost can get so big that it modifies the traced system
often more than acceptable. Under this angle, I would be tempted to say that the
most intrusive instrumentation should be helped by marker, which means accepting
a very small performance impact (NOPs on modern CPUs are quite fast) when
tracing is not active in order to enable fast tracing of some very high event
rate kernel code paths.


>   - model #3: we could have the 'hardest' markups in the source, and the 
>     'easy' ones as dynamic markups in scripts/instrumentation/.
> 
By "hardest", do you mean : where the data that is to be extracted is not easily
available due to compiler optimisations ?

> So my argument isnt "dynamic markup vs. static markup", my argument is: 
> "we shouldnt force the kernel to carry a 100% set of static markups 
> forever". We should allow maintainers to decide the 'mix' of static vs. 
> dynamic markups that they prefer in their subsystem.
> 
We completely agree on this last paragraph.

> i agree, as long as it's lightweight markers for _dynamic tracers_, so 
> that we keep our options open - as per the arguments above.

But I also think that a marker mechanism should not only mark the code location
where the instrumentation is to be made, but also the information the probe is
interested into (provide compile-time data type verification and address at
runtime). Doing otherwise would limit what could be provided to static markup
users.

Mathieu

OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
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