Messages in this thread | | | Date | Sat, 13 Dec 2008 15:26:01 +0100 | From | "Frédéric Weisbecker" <> | Subject | Re: [PATCH 0/3] tracing/function-graph-tracer: signal interrupt triggering on output |
| |
2008/12/13 Ingo Molnar <mingo@elte.hu>: > 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.
| |