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

[Masami Hiramatsu]

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 @@
>>  		(regs)?instruction_pointer(regs):0UL);
>>  }
>>
>> -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
> state.c.

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?

Thank you,

> 
> pmf

-- 
Masami Hiramatsu

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

e-mail: mhiramat at redhat.com