From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Michael Ellerman <michaele@au1.ibm.com>,
linux-kernel@vger.kernel.org,
Stephane Eranian <eranian@google.com>,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Jiri Olsa <jolsa@redhat.com>
Subject: [PATCH 0/3] powerpc/perf: Enable linking with libunwind
Date: Wed, 5 Mar 2014 20:41:56 -0800 [thread overview]
Message-ID: <1394080919-17957-1-git-send-email-sukadev@linux.vnet.ibm.com> (raw)
When we try to create backtraces (call-graphs) with the perf tool
perf record -g /tmp/sprintft
we get backtraces with duplicate arcs for sprintft[1]:
14.61% sprintft libc-2.18.so [.] __random
|
--- __random
|
|--61.09%-- __random
| |
| |--97.18%-- rand
| | do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| |
| --2.82%-- do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--38.91%-- rand
|
|--92.90%-- rand
| |
| |--99.87%-- do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| --0.13%-- [...]
|
--7.10%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
(where the two arcs both have the same backtrace but are not merged).
Linking with libunwind seems to create better backtraces. While x86 and
ARM processors have support for linking with libunwind but Power does not.
This patchset is an RFC for linking with libunwind.
With this patchset and running:
/tmp/perf record --call-graph=dwarf,8192 /tmp/sprintft
the backtrace is:
14.94% sprintft libc-2.18.so [.] __random
|
--- __random
rand
do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
(nil)
This appears better.
One downside is that we now need the kernel to save the entire user stack
(the 8192 in the command line is the default user stack size).
A second issue is that this invocation of perf (with --call-graph=dwarf,8192)
seems to fail for backtraces involving tail-calls[2]
/tmp/perf record -g ./tailcall
gives
20.00% tailcall tailcall [.] work2
|
--- work2
work
shows the tail function 'work2' as "called from" 'work()'
But with libunwind:
/tmp/perf record --call-graph=dwarf,8192 ./tailcall
we get:
20.50% tailcall tailcall [.] work2
|
--- work2
the caller of 'work' is not shown.
I am debugging this, but would appreciate any feedback/pointers on the
patchset/direction:
- Does libunwind need the entire user stack to work or are there
optimizations we can do to save the minimal entries for it to
perform the unwind.
- Does libunwind work with tailcalls like the one above ?
- Are there benefits to linking with libunwind (even if it does not
yet solve the tailcall problem)
- Are there any examples of using libdwarf to solve the tailcall
issue ?
[1] sprintft (excerpt from a test program by Maynard Johnson).
char * do_my_sprintf(char * strx, int num)
{
int i;
for (i = 0; i < inner_iterations; i++) {
int r = rand() % 10;
sprintf(my_string, "%s ...%d\n", strx+r, num);
if (strlen(my_string) > 15)
num = 15;
}
return my_string;
}
[2] tailcall (Powerpc assembly, from Anton Blanchard)
Build with: gcc -O2 --static -nostdlib -o tailcall tailcall.S
#define ITERATIONS 1000000000
.align 2
.globl _start
.globl ._start
.section ".opd","aw"
_start:
.quad ._start
.quad .TOC.@tocbase
.quad 0;
.text;
._start:
lis 4,ITERATIONS@h
ori 4,4,ITERATIONS@l
mtctr 4
1: bl work
bdnz 1b
li 0,1 /* sys_exit */
sc
work:
mflr 30
bl work2
mtlr 30
blr
work2:
blr
Sukadev Bhattiprolu (3):
power: perf: Enable saving the user stack in a sample.
power: perf tool: Add libunwind support for Power
perf: Use 64-bit value when comparing sample_regs
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/uapi/asm/perf_regs.h | 70 ++++++++++++++++++
arch/powerpc/perf/Makefile | 1 +
arch/powerpc/perf/perf-regs.c | 104 +++++++++++++++++++++++++++
tools/perf/arch/powerpc/Makefile | 5 ++
tools/perf/arch/powerpc/include/perf_regs.h | 69 ++++++++++++++++++
tools/perf/arch/powerpc/util/unwind.c | 63 ++++++++++++++++
tools/perf/config/Makefile | 7 ++
tools/perf/util/unwind.c | 4 +-
9 files changed, 323 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
create mode 100644 arch/powerpc/perf/perf-regs.c
create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
create mode 100644 tools/perf/arch/powerpc/util/unwind.c
--
1.7.9.5
next reply other threads:[~2014-03-06 4:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 4:41 Sukadev Bhattiprolu [this message]
2014-03-06 4:41 ` [RFC][PATCH 1/3] power: perf: Enable saving the user stack in a sample Sukadev Bhattiprolu
2014-03-06 4:41 ` [RFC][PATCH 2/3] power: perf tool: Add libunwind support for Power Sukadev Bhattiprolu
2014-03-06 4:41 ` [PATCH 3/3] perf: Use 64-bit value when comparing sample_regs Sukadev Bhattiprolu
2014-03-06 9:44 ` David Laight
2014-03-06 11:33 ` Gabriel Paubert
2014-03-06 17:06 ` Jiri Olsa
2014-03-06 17:49 ` [PATCH 0/3] powerpc/perf: Enable linking with libunwind Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1394080919-17957-1-git-send-email-sukadev@linux.vnet.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=acme@ghostprotocols.net \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michaele@au1.ibm.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).