Re: [PATCH 0/3] tracing/function-graph-tracer: signal interrupt triggering on output

From: Frédéric Weisbecker
Date: Sat Dec 13 2008 - 09:26:18 EST


2008/12/13 Ingo Molnar <mingo@xxxxxxx>:
> that reminds me ... did you know about hardirq_count()? We could use it
> to detect IRQ entries in a more generic way, instead of the section
> trick?


No I didn't know it but thought about it indirectly.
This counter is inc/dec on irq_enter and irq_exit. I wanted first to
send some special events
while entering irq_enter/exit to notice interrupt events. The problem
is that the irq is raised a bit sooner.
If I used I would have:

foo() {
smp_apic_timer_interrupt() {
irq_enter() {
===> //hardirq_count() is incremented here
}
}
}

We would loose so the sense of the arrow here. Its role is to explain
the breakage into
the code flow by the interrupt. The role of the arrow is to explain
that smp_apic_timer_interrupt is not called
by foo().

One thing I would suggest would be to move these irq_enter/exit on entry_xx.S

> Another thing, i just noticed that ftrace_print() is broken in certain
> situations, for example a plain newline:
>
> ftrace_printk("\n");
>
> printed via trace_pipe will print some weirdly concatenated line:
>
> <...>-2994 [007] 406.498986: debug_show: <...>-2994 [007] 406.498986: <...>-2994 [007] 406.498986: debug_show:
>
> not via a separate, standalone, empty line.

Ok, I will send a patch.

>
> Another thing: it would be nice to have a trace_option to leave out this
> preamble:
>
> <...>-2994 [007] 406.498986: debug_show: test printk
>
> and just give this output:
>
> test printk
>
> i.e. some 'printk compatibility' mode. That way i could use
> ftrace_printk() as a pure replacement for printk, during development.
>
> Ingo
>

Ok. I will add a flag for that too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/