This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]