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: Pierre-Marc Fournier <pierre-marc dot fournier at polymtl dot ca>
- Cc: ltt-dev at lists dot casi dot polymtl dot ca, systemtap-ml <systemtap at sources dot redhat dot com>, Hideo AOKI <haoki at redhat dot com>, Takahiro Yasui <tyasui at redhat dot com>
- Date: Tue, 26 Aug 2008 14:39:39 -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>
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@redhat.com