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

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

[Masami Hiramatsu]

Add irq id parameter to irq_exit tracepoint and marker

irq_id parameter is useful for paring irq enter and exit events.

Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Hideo Aoki <haoki@redhat.com>
---
 arch/x86/kernel/apic_32.c                 |    6 +++---
 arch/x86/kernel/apic_64.c                 |    6 +++---
 arch/x86/kernel/cpu/mcheck/mce_intel_64.c |    2 +-
 arch/x86/kernel/cpu/mcheck/p4.c           |    2 +-
 arch/x86/kernel/tlb_32.c                  |    2 +-
 arch/x86/kernel/tlb_64.c                  |    2 +-
 include/trace/irq.h                       |    4 ++--
 kernel/irq/handle.c                       |    2 +-
 kernel/kernel-trace.c                     |    5 +++--
 9 files changed, 16 insertions(+), 15 deletions(-)

Index: linux-2.6-lttng/include/trace/irq.h
===================================================================
--- linux-2.6-lttng.orig/include/trace/irq.h	2008-08-19 21:45:16.000000000 -0400
+++ linux-2.6-lttng/include/trace/irq.h	2008-08-21 14:38:29.000000000 -0400
@@ -9,8 +9,8 @@
 	TPPROTO(unsigned int id, struct pt_regs *regs),
 	TPARGS(id, regs));
 DEFINE_TRACE(irq_exit,
-	TPPROTO(irqreturn_t retval),
-	TPARGS(retval));
+	TPPROTO(unsigned int id, irqreturn_t retval),
+	TPARGS(id, retval));
 DEFINE_TRACE(irq_softirq_entry,
 	TPPROTO(struct softirq_action *h, struct softirq_action *softirq_vec),
 	TPARGS(h, softirq_vec));
Index: linux-2.6-lttng/kernel/irq/handle.c
===================================================================
--- linux-2.6-lttng.orig/kernel/irq/handle.c	2008-08-19 21:45:16.000000000 -0400
+++ linux-2.6-lttng/kernel/irq/handle.c	2008-08-21 14:34:29.000000000 -0400
@@ -153,7 +153,7 @@
 		add_interrupt_randomness(irq);
 	local_irq_disable();

-	trace_irq_exit(retval);
+	trace_irq_exit(irq, retval);

 	return retval;
 }
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));
 }

 static void probe_irq_softirq_entry(struct softirq_action *h,
Index: linux-2.6-lttng/arch/x86/kernel/apic_32.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/apic_32.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/apic_32.c	2008-08-21 16:00:43.000000000 -0400
@@ -638,7 +638,7 @@

 	local_apic_timer_interrupt();

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(LOCAL_TIMER_VECTOR, IRQ_HANDLED);

 	irq_exit();

@@ -1301,7 +1301,7 @@
 	       "should never happen.\n", smp_processor_id());
 	__get_cpu_var(irq_stat).irq_spurious_count++;

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(SPURIOUS_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
@@ -1337,7 +1337,7 @@
 	printk(KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx)\n",
 		smp_processor_id(), v , v1);

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(ERROR_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/apic_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/apic_64.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/apic_64.c	2008-08-21 16:01:05.000000000 -0400
@@ -493,7 +493,7 @@
 	irq_enter();
 	trace_irq_entry(LOCAL_TIMER_VECTOR, regs);
 	local_apic_timer_interrupt();
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(LOCAL_TIMER_VECTOR, IRQ_HANDLED);
 	irq_exit();
 	set_irq_regs(old_regs);
 }
@@ -977,7 +977,7 @@

 	add_pda(irq_spurious_count, 1);

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(SPURIOUS_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
@@ -1014,7 +1014,7 @@
 	printk(KERN_DEBUG "APIC error on CPU%d: %02x(%02x)\n",
 		smp_processor_id(), v , v1);

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(ERROR_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/mce_intel_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/cpu/mcheck/mce_intel_64.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/mce_intel_64.c	2008-08-21 16:01:44.000000000 -0400
@@ -31,7 +31,7 @@

 	add_pda(irq_thermal_count, 1);

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(THERMAL_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/p4.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/cpu/mcheck/p4.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/p4.c	2008-08-21 16:01:25.000000000 -0400
@@ -67,7 +67,7 @@
 	vendor_thermal_interrupt(regs);
 	__get_cpu_var(irq_stat).irq_thermal_count++;

-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(THERMAL_APIC_VECTOR, IRQ_HANDLED);

 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/tlb_32.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/tlb_32.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/tlb_32.c	2008-08-21 16:02:02.000000000 -0400
@@ -124,7 +124,7 @@
 out:
 	put_cpu_no_resched();
 	__get_cpu_var(irq_stat).irq_tlb_count++;
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(INVALIDATE_TLB_VECTOR, IRQ_HANDLED);
 }

 void native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,
Index: linux-2.6-lttng/arch/x86/kernel/tlb_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/tlb_64.c	2008-08-19 21:45:13.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/tlb_64.c	2008-08-21 16:02:21.000000000 -0400
@@ -159,7 +159,7 @@
 	ack_APIC_irq();
 	cpu_clear(cpu, f->flush_cpumask);
 	add_pda(irq_tlb_count, 1);
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(sender, IRQ_HANDLED);
 }

 void native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,



-- 
Masami Hiramatsu

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

e-mail: mhiramat@redhat.com

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

[Pierre-Marc Fournier]

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.

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.

pmf

Re: [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@redhat.com

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

[KOSAKI Motohiro]

> Add irq id parameter to irq_exit tracepoint and marker
> 
> irq_id parameter is useful for paring irq enter and exit events.
> 
> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
> Signed-off-by: Hideo Aoki <haoki@redhat.com>

ok.
looks good to me.

Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

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

[Mathieu Desnoyers]

* Masami Hiramatsu (mhiramat@redhat.com) wrote:
> 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.
> 

If you start losing events, having the irq id at irq_exit won't help
you, since you may be losing random irq entry/exit events and think you
are pairing correct events when in fact you pair two unrelated
entry/exit event. I therefore do not think we have to consider any
correctness issue about the information gathered when we have to drop
events. The trace viewer should be solid enough so it does not crash
though, and maybe detect inconsistency, but that's about it. I would not
add a performance cost for such a corner-case.

> 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.

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.


> 
> > 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.

Mathieu


> Thank you,
> 
> > 
> > pmf
> 
> -- 
> Masami Hiramatsu
> 
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
> 
> e-mail: mhiramat@redhat.com
> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

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

[Masami Hiramatsu]

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

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

[Mathieu Desnoyers]

* Masami Hiramatsu (mhiramat@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,

Thanks,

Mathieu

> 
> -- 
> Masami Hiramatsu
> 
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
> 
> e-mail: mhiramat@redhat.com
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

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

[Masami Hiramatsu]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

Mathieu Desnoyers wrote:
> * Masami Hiramatsu (mhiramat@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@redhat.com


[-- Attachment #2: lttng-irq-tracepoint-modify.patch --]
[-- Type: text/plain, Size: 6218 bytes --]

Add irq id parameter to irq_exit tracepoint and marker

irq_id parameter is useful for paring irq enter and exit events.

Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Hideo Aoki <haoki@redhat.com>
---
 arch/x86/kernel/apic_32.c                 |    6 +++---
 arch/x86/kernel/apic_64.c                 |    6 +++---
 arch/x86/kernel/cpu/mcheck/mce_intel_64.c |    2 +-
 arch/x86/kernel/cpu/mcheck/p4.c           |    2 +-
 arch/x86/kernel/tlb_32.c                  |    2 +-
 arch/x86/kernel/tlb_64.c                  |    2 +-
 include/trace/irq.h                       |    4 ++--
 kernel/irq/handle.c                       |    2 +-
 kernel/kernel-trace.c                     |    2 +-
 9 files changed, 14 insertions(+), 14 deletions(-)

Index: linux-2.6-lttng/include/trace/irq.h
===================================================================
--- linux-2.6-lttng.orig/include/trace/irq.h	2008-09-12 15:00:04.000000000 -0400
+++ linux-2.6-lttng/include/trace/irq.h	2008-09-12 15:07:59.000000000 -0400
@@ -9,8 +9,8 @@
 	TPPROTO(unsigned int id, struct pt_regs *regs),
 	TPARGS(id, regs));
 DEFINE_TRACE(irq_exit,
-	TPPROTO(irqreturn_t retval),
-	TPARGS(retval));
+	TPPROTO(unsigned int id, irqreturn_t retval),
+	TPARGS(id, retval));
 DEFINE_TRACE(irq_softirq_entry,
 	TPPROTO(struct softirq_action *h, struct softirq_action *softirq_vec),
 	TPARGS(h, softirq_vec));
Index: linux-2.6-lttng/kernel/irq/handle.c
===================================================================
--- linux-2.6-lttng.orig/kernel/irq/handle.c	2008-09-12 15:00:04.000000000 -0400
+++ linux-2.6-lttng/kernel/irq/handle.c	2008-09-12 15:07:59.000000000 -0400
@@ -153,7 +153,7 @@
 		add_interrupt_randomness(irq);
 	local_irq_disable();
 
-	trace_irq_exit(retval);
+	trace_irq_exit(irq, retval);
 
 	return retval;
 }
Index: linux-2.6-lttng/kernel/kernel-trace.c
===================================================================
--- linux-2.6-lttng.orig/kernel/kernel-trace.c	2008-09-12 15:00:04.000000000 -0400
+++ linux-2.6-lttng/kernel/kernel-trace.c	2008-09-12 15:08:47.000000000 -0400
@@ -18,7 +18,7 @@
 		(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));
 }
Index: linux-2.6-lttng/arch/x86/kernel/apic_32.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/apic_32.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/apic_32.c	2008-09-12 15:07:59.000000000 -0400
@@ -638,7 +638,7 @@
 
 	local_apic_timer_interrupt();
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(LOCAL_TIMER_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 
@@ -1301,7 +1301,7 @@
 	       "should never happen.\n", smp_processor_id());
 	__get_cpu_var(irq_stat).irq_spurious_count++;
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(SPURIOUS_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
@@ -1337,7 +1337,7 @@
 	printk(KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx)\n",
 		smp_processor_id(), v , v1);
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(ERROR_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/apic_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/apic_64.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/apic_64.c	2008-09-12 15:07:59.000000000 -0400
@@ -492,7 +492,7 @@
 	irq_enter();
 	trace_irq_entry(LOCAL_TIMER_VECTOR, regs);
 	local_apic_timer_interrupt();
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(LOCAL_TIMER_VECTOR, IRQ_HANDLED);
 	irq_exit();
 	set_irq_regs(old_regs);
 }
@@ -976,7 +976,7 @@
 
 	add_pda(irq_spurious_count, 1);
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(SPURIOUS_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
@@ -1013,7 +1013,7 @@
 	printk(KERN_DEBUG "APIC error on CPU%d: %02x(%02x)\n",
 		smp_processor_id(), v , v1);
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(ERROR_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/mce_intel_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/cpu/mcheck/mce_intel_64.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/mce_intel_64.c	2008-09-12 15:07:59.000000000 -0400
@@ -31,7 +31,7 @@
 
 	add_pda(irq_thermal_count, 1);
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(THERMAL_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/p4.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/cpu/mcheck/p4.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/cpu/mcheck/p4.c	2008-09-12 15:07:59.000000000 -0400
@@ -67,7 +67,7 @@
 	vendor_thermal_interrupt(regs);
 	__get_cpu_var(irq_stat).irq_thermal_count++;
 
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(THERMAL_APIC_VECTOR, IRQ_HANDLED);
 
 	irq_exit();
 }
Index: linux-2.6-lttng/arch/x86/kernel/tlb_32.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/tlb_32.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/tlb_32.c	2008-09-12 15:07:59.000000000 -0400
@@ -124,7 +124,7 @@
 out:
 	put_cpu_no_resched();
 	__get_cpu_var(irq_stat).irq_tlb_count++;
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(INVALIDATE_TLB_VECTOR, IRQ_HANDLED);
 }
 
 void native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,
Index: linux-2.6-lttng/arch/x86/kernel/tlb_64.c
===================================================================
--- linux-2.6-lttng.orig/arch/x86/kernel/tlb_64.c	2008-09-12 15:00:00.000000000 -0400
+++ linux-2.6-lttng/arch/x86/kernel/tlb_64.c	2008-09-12 15:07:59.000000000 -0400
@@ -159,7 +159,7 @@
 	ack_APIC_irq();
 	cpu_clear(cpu, f->flush_cpumask);
 	add_pda(irq_tlb_count, 1);
-	trace_irq_exit(IRQ_HANDLED);
+	trace_irq_exit(sender, IRQ_HANDLED);
 }
 
 void native_flush_tlb_others(const cpumask_t *cpumaskp, struct mm_struct *mm,

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

[Ingo Molnar]

* Masami Hiramatsu <mhiramat@redhat.com> wrote:

> Add irq id parameter to irq_exit tracepoint and marker
> 
> irq_id parameter is useful for paring irq enter and exit events.
> 
> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
> Signed-off-by: Hideo Aoki <haoki@redhat.com>
> ---
>  arch/x86/kernel/apic_32.c                 |    6 +++---
>  arch/x86/kernel/apic_64.c                 |    6 +++---
>  arch/x86/kernel/cpu/mcheck/mce_intel_64.c |    2 +-
>  arch/x86/kernel/cpu/mcheck/p4.c           |    2 +-
>  arch/x86/kernel/tlb_32.c                  |    2 +-
>  arch/x86/kernel/tlb_64.c                  |    2 +-
>  include/trace/irq.h                       |    4 ++--
>  kernel/irq/handle.c                       |    2 +-
>  kernel/kernel-trace.c                     |    2 +-
>  9 files changed, 14 insertions(+), 14 deletions(-)

all these files conflict with tip/master in a non-trivial way. apic.c 
got unified, mce and tlb reworked. Could you please resend against 
tip/master? Thanks,

	Ingo

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

[Masami Hiramatsu]

Ingo Molnar wrote:
> * Masami Hiramatsu <mhiramat@redhat.com> wrote:
> 
>> Add irq id parameter to irq_exit tracepoint and marker
>>
>> irq_id parameter is useful for paring irq enter and exit events.
>>
>> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
>> Signed-off-by: Hideo Aoki <haoki@redhat.com>
>> ---
>>  arch/x86/kernel/apic_32.c                 |    6 +++---
>>  arch/x86/kernel/apic_64.c                 |    6 +++---
>>  arch/x86/kernel/cpu/mcheck/mce_intel_64.c |    2 +-
>>  arch/x86/kernel/cpu/mcheck/p4.c           |    2 +-
>>  arch/x86/kernel/tlb_32.c                  |    2 +-
>>  arch/x86/kernel/tlb_64.c                  |    2 +-
>>  include/trace/irq.h                       |    4 ++--
>>  kernel/irq/handle.c                       |    2 +-
>>  kernel/kernel-trace.c                     |    2 +-
>>  9 files changed, 14 insertions(+), 14 deletions(-)
> 
> all these files conflict with tip/master in a non-trivial way. apic.c 
> got unified, mce and tlb reworked. Could you please resend against 
> tip/master? Thanks,

Hi Ingo,

Would you have pulled lttng's irq tracing commits from lttng-git tree?
This patch depends on below 2 commits. So, currently, this patch is
for lttng-git tree.

http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=commit;h=685e0d885c91043a6b0451f4ae795bbe359db502
http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=commit;h=3161b650ce96173ead26572ceb2d12592262cf55

Thank you,

-- 
Masami Hiramatsu

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

e-mail: mhiramat@redhat.com