This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [ltt-dev] [LTTng][RFC][Patch 2/2] add irq-id parameter to irq_exit tracepoint and marker
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: Pierre-Marc Fournier <pierre-marc dot fournier at polymtl dot ca>, ltt-dev at lists dot casi dot polymtl dot ca, Hideo AOKI <haoki at redhat dot com>, Takahiro Yasui <tyasui at redhat dot com>, systemtap-ml <systemtap at sources dot redhat dot com>
- Date: Fri, 12 Sep 2008 12:42:40 -0400
- Subject: Re: [ltt-dev] [LTTng][RFC][Patch 2/2] add irq-id parameter to irq_exit tracepoint and marker
- References: <48B4220A.4020505@redhat.com> <48B430AF.8080208@polymtl.ca> <48B44DEB.90504@redhat.com> <20080910223540.GE23197@Krystal>
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,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com