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

[Masami Hiramatsu]

Mathieu Desnoyers wrote:
> * Masami Hiramatsu (mhiramat at 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,

Of cause, I can :-) here I removed modification of markers.

Thank you so much,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat at redhat.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lttng-irq-tracepoint-modify.patch
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20080912/2d30541c/attachment-0001.asc>