3

I really like the idea of the Flame Graph for profiling since it will help in eliminating unneeded function calls. There is a catch however in that it requires the profiler to do a complete stack dump each time it collects a sample. This can be accomplished with DTrace or SystemTap quite easily, but I need to be able to do this on an ARM device running ubuntu (which eliminates DTrace). I would also like to do this without recompiling the kernel (which eliminates SystemTap).

Is it possible to get Valgrind/Callgrind or OProfile (or some other profiling tool that can run on an ARM device in Ubuntu) to output something similar to:
dtrace -n 'profile-1001 /pid == 12345 && arg1/ { @[ustack()] = count(); }

Leo
  • 2,328
  • 2
  • 21
  • 41
  • 1
    Possibilities: *[pstack](http://linuxcommand.org/man_pages/pstack1.html)*, or *[poor man's profiler](http://poormansprofiler.org/)* that uses gdb to get stack traces. – Mike Dunlavey Apr 26 '12 at 12:41
  • pstack looks promising, I would like something a bit more automated than poor man's profiler though. – Leo Apr 26 '12 at 13:11
  • Check for the existence of */proc//stack*. This will give the kernel stack for a process. Something different, but possibly useful. The `gdb` solution will only trace *user space*. Ie, you can see where the kernel is spending time on behalf of your process. You should probably remove the tag *dtrace* and add *linux*. – artless noise Jun 05 '14 at 17:01

2 Answers2

9

Try Linux perf_events (aka the "perf" command), which is part of the mainline Linux kernel, and usually installed via the linux-tools-common (or similar) package. I often use it to create flame graphs on Linux.

I wrote up some instructions for creating flame graphs with perf on: http://www.brendangregg.com/perf.html#FlameGraphs

Brendan Gregg
  • 965
  • 8
  • 10
  • + Just upvoted you 'cause nobody should have low rep :) I believe in wall-time stack samples, though you might know I don't get excited about flame graphs. Cheers. – Mike Dunlavey Jun 04 '14 at 19:18
1

pstack was suggested by Mike Dunlavey which unfortunately segfaults after I apply the ARM patch and run it on an ARM device. Until I have time to take a look at it, I found the following stopgap solution:

http://www.commandlinefu.com/commands/view/4039/print-stack-trace-of-a-core-file-without-needing-to-enter-gdb-interactively

It uses gdb with the following command: gdb --q --n --ex bt --batch --pid PID

A bit slow but works.

Leo
  • 2,328
  • 2
  • 21
  • 41