[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090701081814.GA25593@elte.hu>
Date: Wed, 1 Jul 2009 10:18:14 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Mike Galbraith <efault@....de>,
Paul Mackerras <paulus@...ba.org>,
Anton Blanchard <anton@...ba.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 0/3] perfcounter: callchain symbol resolving and fixes
* Frederic Weisbecker <fweisbec@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists