[ltt-dev] [LTTng][RFC][Patch 2/2] add irq-id parameter to irq_exit tracepoint and marker
mhiramat at redhat.com
Tue Aug 26 14:39:39 EDT 2008
Pierre-Marc Fournier wrote:
> Masami Hiramatsu wrote:
>> Index: linux-2.6-lttng/kernel/kernel-trace.c
>> --- linux-2.6-lttng.orig/kernel/kernel-trace.c 2008-08-19 21:45:16.000000000 -0400
>> +++ linux-2.6-lttng/kernel/kernel-trace.c 2008-08-21 15:58:39.000000000 -0400
>> @@ -18,9 +18,10 @@
>> -static void probe_irq_exit(irqreturn_t retval)
>> +static void probe_irq_exit(unsigned int id, irqreturn_t retval)
>> - trace_mark(kernel_irq_exit, "handled #1u%u", IRQ_RETVAL(retval));
>> + trace_mark(kernel_irq_exit, "irq_id %u handled #1u%u",
>> + id, IRQ_RETVAL(retval));
> This is redundant information. The IRQ id is already specified in
> kernel_irq_entry events. The IRQ id of a kernel_irq_exit event can be
> known by keeping a stack of nested IRQs, as is done in LTTV in the file
I think it helps some corner case when we dropped irq entry event
from memory(or pushed away from log). I know it is just a rare case,
but it will happen.
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.
> 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?
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat at redhat.com
More information about the lttng-dev