Re: [ltt-dev] [LTTng][RFC][Patch 2/2] add irq-id parameter to irq_exit tracepoint and marker

[Mathieu Desnoyers <compudj@krystal.dyndns.org>]

* Masami Hiramatsu (mhiramat@redhat.com) wrote:
> Hi Mathieu,
> 
> Mathieu Desnoyers wrote:
> >> And when we use these markers not from LTTng (ex. systemtap),
> >> it could be handled as isolated events. For example, I can check which
> >> irq handler returns error by tracing ONLY irq_exit events, with this patch.
> >>
> > 
> > Hrm, this is precisely why I created the tracepoints. I would be all in
> > to add a struct pt_regs parameter and a irq id parameter to the irq exit
> > _tracepoint_ (since this is a kernel internal API), but I am very
> > reluctant to add it to the marker, given it will add useless information
> > in the traces.
> 
> Indeed. What we really need is additional parameters for tracepoints, not
> markers, because markers can't get parameters which are not passed from
> tracepoints. ;-)
> LTTng's conversion module can filter those parameters for LTTng
> or some other tracers which use LTTng markers.
> 
> > I propose that systemtap move to tracepoints instead of markers, given
> > that they run in kernel-space anyway. It'a really a plus to have correct
> > typing of pointers, structures, etc.
> 
> The difficulty of using tracepoints directly is parsing native C
> code to get parameters. If each tracer can have its conversion module,
> I think we don't need to do so.
> 
> >>> Here we need to compromise between the trace size and the amount of work
> >>> needed to analyze the trace. kernel_irq_exit is a very high rate event
> >>> and the work needed to keep track of the state is small. Therefore I
> >>> doubt including the redundant information is the best choice.
> >> Indeed, could LTTng ignores(or filters) the parameter?
> >>
> > 
> > LTTng just parses the format string and dumps them to userspace. Since I
> > developed the tracepoints, I see more and more the markers as being a
> > "binary formatting" infrastructure more closely tied to LTTng. But
> > tracepoints are taking over, so there is no features removed, just added
> > flexibility for in-kernel tracers.
> 
> BTW, if so, I think we can make various versions of tracepoint-marker
> conversion modules for LTTng and other in-kernel tracers.
> 
> Thank you,
> 

Yep, I agree. Could you rearrange your patch against LTTng
instrumentation to only add the irq exit tracepoint parameter you need ?
I would be glad to merge that,

Thanks,

Mathieu

> 
> -- 
> Masami Hiramatsu
> 
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
> 
> e-mail: mhiramat@redhat.com
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68