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

["Frédéric Weisbecker" <fweisbec@gmail.com>]

2008/12/12 Ingo Molnar <mingo@elte.hu>:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
>> Frederic Weisbecker wrote:
>> > This patchset adds all the features to draw hardirq triggering on output
>> > for the function graph tracer.
>> > An example is given on the third patch.
>> >
>> > Just one question, on recordmcount.pl:
>> >
>> > my %text_sections = (
>> >       ".text" => 1,
>> >       ".sched.text" => 1,
>> >       ".spinlock.text" => 1,
>> >
>> > The .sched.text section is included inside .text, it's a subsection, I'm not sure
>> > it's necessary to add it in text_sections. In doubt I added the new .irqentry.text
>> >
>> > The stat of the patchset:
>> >
>> >  arch/x86/kernel/apic.c               |    3 +-
>> >  arch/x86/kernel/irq_64.c             |    3 +-
>> >  arch/x86/kernel/vmlinux_64.lds.S     |    1 +
>> >  include/asm-generic/vmlinux.lds.h    |   10 +++++
>> >  include/linux/ftrace.h               |   11 ++++++
>> >  kernel/trace/trace_functions_graph.c |   66 +++++++++++++++++++++++++++++++--
>> >  scripts/recordmcount.pl              |    1 +
>> >  7 files changed, 89 insertions(+), 6 deletions(-)
>
> applied to tip/tracing/function-graph-tracer, thanks Frederic!
>
> The output looks really nice.
>
>        Ingo
>

Thanks :-)

If anyone  has other needs or suggestions about this tracer, don't
hesitate to request it.
I remember Peter suggested that the preempt count could be output.
Actually, to make the things more humans, I would suggest to simply
output the fact that preempt is disabled or not.

I could for example give three more fields with one letter for each
(as a default-off trace option):

_interrupt disabled
_preempt disabled
_in atomic context

I guess those could help for the -rt tree for example.
What do you think?

When I worked on this hardirq signal, I wanted to print the current
code context for each function:

Interrupt:
_ Hardirq
_ Softirq (with subclasses like tasklets)
_ Nmi (not yet traced, if there are still plans for the ring buffer to
be lockless, that will be easy).

Task:
_Syscall
_Workqueue
_kernel thread

But actually, those things are easy to find if the current task/pid is
output. "ksoftirqd", "events" are here to give
the hints about the softirq and workqueue context. Syscalls are easy
to find along the code flow. Kernel threads are
recognized through their name. And hardirqs have their arrows....

But if you think such a column could be useful for you or anyone, just tell me.

There is still some work remaining, the braces on leaf functions have
to disappear on the trace_pipe (but it requires
to read the ring-buffer on more than one entry forward, just two actually).

And a port to other archs. I will try to acquire a low cost arm board
if I can (I wouldn't feel comfortable with qemu).

Anyway, most of these things will be for 2.6.30 I guess :-)