Re: [PATCH 0/3] perfcounter: callchain symbol resolving and fixes

[Ingo Molnar <mingo@elte.hu>]

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> Hi,
> 
> This patchset provides the symbol resolving for callchains.
> Example:
> 
> perf report -s sym -c
> 
> 5.40%  [k] __d_lookup
>              3.60%
>                 __d_lookup
>                 perf_callchain
>                 perf_counter_overflow
>                 intel_pmu_handle_irq
>                 perf_counter_nmi_handler
>                 notifier_call_chain
>                 atomic_notifier_call_chain
>                 notify_die
>                 do_nmi
>                 nmi
>                 do_lookup
>                 __link_path_walk
>                 path_walk
>                 do_path_lookup
>                 user_path_at
>                 vfs_fstatat
>                 vfs_lstat
>                 sys_newlstat
>                 system_call_fastpath
>                 __lxstat
>                 0x406fb1

nice!

> Sorry about the third patch, it's a kind of all-in-one monolithic 
> thing which gathers various fixes. I should have granulate it...

No problem, it's good enough - it's all about the same topic.

> 
> Still in my plans:
> 
> - profit we have a tree to display a better graph hierarchy
> - let the user provide a limit for hit percentage, depth, number of
>   backtraces, etc...
> - better output
> - colors
> 
> And another one:
> 
> - remove the perfcounter internal nmi call frame (ie: every nmi frame)
>   so that we drop this header from each callchain:
> 
>                 perf_callchain
>                 perf_counter_overflow
>                 intel_pmu_handle_irq
>                 perf_counter_nmi_handler
>                 notifier_call_chain
>                 atomic_notifier_call_chain
>                 notify_die
>                 do_nmi
>                 nmi

Sounds good. I suspect this latter one is the most important one 
because right now the backtrace output screen real estate is 
dominated by the repetitive nmi entries, making it hard to interpret 
the result 'at a glance'.

I think we should skip those NMI entries right in the kernel - that 
will also make call-chain event records quite a bit smaller, by 
about 72 bytes per call-chain record.

We can do the skipping by using this backtrace-generator callback in 
arch/x86/kernel/cpu/perf_counter.c:

 static int backtrace_stack(void *data, char *name)
 {
         /* Process all stacks: */
         return 0;
 }

The 'name' parameter passed in signals the type of stack frame we 
are processing. If you look into arch/x86/kernel/dumpstack_64.c, it 
can be one of these strings:

        static char ids[][8] = {
                [DEBUG_STACK - 1] = "#DB",
                [NMI_STACK - 1] = "NMI",
                [DOUBLEFAULT_STACK - 1] = "#DF",
                [STACKFAULT_STACK - 1] = "#SS",
                [MCE_STACK - 1] = "#MC",

A quick check to see whether this concept works would be expose the 
ids array and do:

 static int PER_CPU(int, is_nmi_frame);

 static int backtrace_stack(void *data, char *name)
 {
	if (name == x86_stack_ids[NMI_STACK-1])
		per_cpu(is_nmi_frame, raw_processor_id()) = 1;
	else
		per_cpu(is_nmi_frame, raw_processor_id()) = 0;

        /* Process all stacks: */
        return 0;
 }

and to add something like this to backtrace_address():

	if (per_cpu(is_nmi_frame, raw_processor_id())
		return;

	Ingo